Building Great Products in a Remote World with Asana Chief Product Officer Alex Hood

Hi everybody, thanks for joining me from wherever you are in the world. Gosh, we were supposed to do this live at Saster months and months ago, but now the whole world has changed. So I want to talk about how to build products in that changed world where we are working at distance and not sharing oxygen. Here's the premise of this conversation: product teams, you hire product teams to do creative work, and there's a tax, and the tax right now is too high. We spend 60% of our time as information workers doing work about work. That is trolling through email, getting hit up with a bunch of notifications, sitting in status meetings. It's the work that facilitates the work, but it's not the actual thing. It's not the deliverable, it's not the spec that needs to be written, or the design that's created, or the code that's entered. So that's sad. Imagine this for 1.25 billion information workers. That is a massive, massive problem. And lay on top of that COVID. So regaining time to focus on the work that matters might be the best way for you to serve your team. 83% of teams feel like they're not as effective as they could be because their process is not that great. And on average, we're spending 10% of our time, about four and a half hours, duplicating work that's already been done. I think that's one of the worst parts of work, often ending up as that Friday afternoon status report. I also just read in Harvard Business Review that with COVID, everybody got 53 minutes back on average from their commute, and that 53 minutes went straight to work about work, not to creative work. It went to the lowest value work out there. So regaining that focus really makes a difference. You feel it, I feel it. It is so easy to get burnt out in this COVID world, and for your product teams who you want to perform, to build the great things, to have energy zapped. These are some stats that we collected before COVID: 82% feeling like they're close to burnout, 47% feel like it has a negative impact on their mood, and 43% feel like it's holding them back from advancing work. Fast forward to where we are now, I'd say probably it's 100% or 75%. So we're probably in the business of getting the most out of our teams that we're on or that we lead. How do we do that? Well, here's a complicating factor. Over time, starting in the 2000s up to where we are now, it takes that much more back and forth, call it collaboration, number of messages to get the same incremental unit of productivity. Collaboration is growing exponentially, productivity is growing linearly, roughly the pace of inflation. That back and forth happens because there's a lack of clarity: who's doing what by when, who's on first, what's the plan, who's accountable, what are we actually doing here? That's where a lot of that 60% of work about work is actually generated. So the biggest gift to your team could be to reduce the amount of quote-unquote collaboration, which is really just the back and forth nonsense, so that you're able to focus on building great stuff. I know a few ways to do this. The first is having a customer focus. A lot of startups are in a situation where the founder gets to make a lot of the calls, and the highest paid person in the room gets to have an opinion that weighs out everybody else. It might have worked when everybody was working in an office, but what's scalable is teaching your product teams how to be really customer focused, because they'll be much more likely to build the right things. There are vision-led companies where your team has to guess what the founder might be thinking, sales-led companies where you're waiting for input from sales teams, committee-led which is the worst, and then customer-led. The customer-led one is probably more gratifying to work at, and it's much more likely that what you build solves a big customer problem and has product market fit because you had the customer in mind when you built it. Here's the process that we use at Asana, and it's similar to other processes out there. It's called the double diamond. At Intuit, where I worked before, we called it Design for Delight. It's human-centered design. IDEO helps publicize and socialize this. It really is a couple things: number one, you focus on the pain before you focus on the solution. Number two, you leave yourself time to go broad, to discover, to look at the problem from all different perspectives, to do research, to get empathy, and then you refine and get down to a very specific pain point for a very specific customer type. Only when you've agreed on that, then you go brainstorm. A lot of folks brainstorm first, which probably ends up for the worst. So you go brainstorm after you've got that deep customer empathy, all that data around what the customer pain is, how it manifests, it's pumping through your whole team's veins. Then you start to narrow on what's the ideal customer experience, how do we work backwards from that. It's like the Eric Ries methodology. You narrow based on your knowledge and your empathy of what is that very specific pain for that very specific person. You lay it on a framework like this, and what comes out of the end is much more likely to win than if you had just started with brainstorming, because it actually solves the problem. A lot of the time you spend as a startup is trying to have a solution, and the solution doesn't solve a big problem. It's almost like you're stubbing your toe before you start the race. At Asana, we actually have codified what the workflow is for a product team to make its way through this double diamond. It starts with a debrief and identifying the target pain, doing a kickoff once we have an idea of what our vision is, then doing a spec review and a series of design reviews into launch review. From the perspective of now managing remotely, if we're on the same page of what the process is, what the checkpoints are, and what's expected at the checkpoints, that makes the team's life better, makes your life better, and there's much less back and forth and work about work to build a great product. This is Asana. It's the system that we build, but we also use to build product. In Asana, assign is kind of the plan of record of who's doing what by when for all the projects that happen in the company. Here is our product toolkit, which maps exactly to these checkpoints. We have clarity around what is expected from each of these checkpoints. Not every team has to go through all the checkpoints, but at least you have to go through the rigor. Inside Asana, there are key questions, basically pre-publishing what we should be doing at each one of these phases. So any product manager, designer, engineer who is building something can take a look at what needs to get done and know what the rigor is expected of them, instead of laboring over some new framework that they're building themselves. Clarity of expectations is really helpful. So that was about being customer-centric and how we do it at Asana. The second piece is what are the tools that you use. I say this because I really feel like the tools that we use to collaborate ideas and share ideas have largely not evolved in the last 25 years. That is really the form factor of the Microsoft Office suite: Excel, email, PowerPoint, Word docs. How much of your time do you spend in something that looks, feels, and smells like those things? Google really popularized getting those form factors in the cloud, but it still exists as those form factors. So if you are concerned about your team doing work about work, maybe that form factor is not serving you as well. At Asana, we feel like great teams have three things: they've got a place where their content lives, that's important; they've got a place where communications live, like messaging, Slack, email, Zoom; and there's also a coordination layer, that's the who's doing what by when, who's accountable. We really believe that you do your best work when you don't have to ask anybody to know all the things that you rely on to get your job done are coming along in real time, and you also know that you're going to have more fun at work if you know how your work ladders up to something greater. That's what the coordination or work management does. So you can check if you haven't checked out something like Asana, you might want to. Here is a project in Asana, a big cross-functional project for a community mobile app launch. Product marketers and engineers contribute to it, and you can really see how all the pieces come together. You can pivot that same project into Kanban, you can plan right to left in a Gantt or timeline view. All this uses the same underlying data, so you click on one of these tasks, it's the same task as one of these cards, just presented in a different way. So you might want to get yourself a plan of record. If you invested in that, you'd find yourself with a lot fewer pings. You also might wake up early in the morning, like I feel sometimes, and think, 'Oh man, what's going on with that thing?' The dangerous thing is you go and ping a bunch of your colleagues, and then they wake up to anxiety because you want to know the status of something. What if you had a tool that just told you what status was automatically by virtue of the work being updated in it? That saves you anxiety, it saves your teammates anxiety, and it also builds trust. So that's the second piece. I started with being customer-centric as a scaling opportunity. It allows folks that work at home to come to the best conclusions without having to have a bunch of meetings where opinions are back and forth. Number two, the toolkit: if you had a toolkit of what the plan of record is, then you don't have to say goodbye to the latest point of record in Slack or in Teams when GIFs get added to a work stream and you'll never find where you agreed the plan of record ever again. Lastly, I think there's something here around protecting the focus of your team. Back to that 60% of time that we spend on work about work. I spent all my time trying to hire really awesome product people, designers, engineers, product managers, and researchers to do their craft, to do the thing that they're passionate about, to innovate, come up with something amazing that customers will love or come up with some great new learning. If you tax them with work about work or lack of clear priorities, then they just end up chasing their tail. So I might challenge you to really think about protecting the personal flow time of your team as a highly scaled operation for you to do as a leader. We do this at Asana by publishing your intention of what you're doing, so people are less likely to ping you. There are other tools that do that as well. Also, have really great one-on-ones. One-on-ones make a huge difference. If you've got a place where you've got your agendas for your one-on-ones already created, you can look at them together. That makes a big difference. If you have one-on-ones, those who have one-on-ones are three times more likely to stay at their job and twice as likely to be engaged. Taking that time to get synced, have that Martian mind meld, share oxygen, is super important. It takes a lot of the back and forth out of collaboration. In many tools, you can just see eye to eye, and that will save a bunch of time later. I spent a lot of time thinking about what drives individual performance and what drives employee engagement, because that is the business that I am in. I'm building tools for the big pain points in the space. Here's a big aha: there are things that drive individual performance. I'll list them: clarity of knowing who's doing what and why it's important, knowing how the thing that you're doing contributes up to something greater, getting rewarded for your great work, knowing how well you're doing along the way, and being free from distractions. Those are the drivers of individual high performance. Employee engagement is something that if you're at a larger company, it's measured and tracked over time because it's a best practice to survey your team and see how they're doing. The companies who do this best have narrowed down the things that drive high performing organizations that are highly engaged. Number one, recognition for high performers. Number two, everybody has a clear sense of the strategy, it's very well communicated. Number three, everybody can see how their personal work aligns to something bigger. You may notice there's some redundancy because the very same drivers of individual high performance are the same drivers of employee engagement writ large across an organization: having clarity, having a reward structure for the work that matters most, and reducing the nonsense so that you can actually get work done. So that's great for individuals to maximize their time, and it's also going to lead to better outcomes as an organization. So to say this as a long story, actually protecting your time and maximizing the things that drive the focus of your team, the flow, clarity, reward system, freedom from distractions, makes a big difference to overall organizational results. I'm kind of a leadership buff, so I think about leadership a lot. I lead a team here, and I think about servant leadership. There are three phases of servant leadership, and I challenge you to really consider the third phase. The first phase is making sure your team is unblocked, that they're not stuck on decisions and spinning their wheels. The second phase of servant leadership is celebrating failures. You want your folks to work on bold initiatives, to innovate, to experiment, to be creative, to have creative safety in their work. One way you do that is you be hypothesis-driven, you allow experimentation to occur, you celebrate failures. Those two things are pretty widely understood and known. I think though, now particularly in the time of COVID, when your product teams are remote, protecting their flow can be one of your primary jobs as a leader. It doesn't mean you need to be the person these folks report to. If you're a product manager, you might think twice before pinging the whole crew. You might really be intentional about how your team sets up their time, shares their time together versus not. You might actually think about what are the things that we can do async. Can we get on the same page by just reading a doc and passing that back and forth instead of having to have a meeting all the time? What are the right things and conventions that we should be pinging each other on on messaging versus things that we shouldn't? How do you create artifacts that are durable so that folks can be up to speed? Protecting the time, reducing that 60% of work about work, particularly in COVID where parents are trying to figure out how to get their kids back on Zoom, or they're half child care, half coding, or they're dealing with the loneliness of COVID and it's harder to stay focused, or maybe they haven't been in their career that long and they get easily distracted, or they did exhaustion. Protecting that focus and flow time, when I say flow time I mean that time where time passes by really fast, you're really deeply ingrained in your work. That's what you really want your folks to do. I think it's undervalued. I think our current teams, our current tools don't support it. I think you could architect how your teams work to better support it. So that's it. Those are the points I wanted to share. When I look back at how I seek to architect how our teams work: a deep customer focus scales. If you have a system where the right decisions are being made for customers, everybody knows how the systems work, what's expected of them, the decisions that come out of it will be better and there will be less drama along the way, actually less back and forth. Number two, you have a toolkit where accountability lives, who's doing what by when, see how the pieces actually fit together, get yourself off of the old toolkits that don't work quite as well. And third, be intentional about the focused time of your folks and make sure that they're intentional with the use of that time as well. If you can take that 60% of work about work time and get it back to 40%, what a service you've done to your team. You'll give them a whole day to create and innovate, and that's what you really want. So that's my two cents on building products remotely, and I'm more than happy to answer any questions.

All right, let me just take stock of our questions here. Yeah, there's a great question here about how about teams across time zones. I have empathy for that because I've worked on development teams that were 13 hours away from where I worked, and that was the PM and the engineers were that far away. I'll tell you, if you aren't clear, if there's a misunderstanding, if you aren't intentional with your words or what you type, then you miss a whole cycle. You miss 13 hours of folks trying to decode what you're saying, wasting a bunch of time, and then them asking you a bunch of questions until you can respond. Such a waste of time. Talk about work about work that happens in hours and not minutes. So I think really getting clear on artifacts that can be consumed async, get clear with your team on what can be done either by taking a look at a document, commenting on it, using something like Asana, having a ticketing system, or do more written and hire people who are great writers, not just great evangelists or great talkers. Great writers matter too. Focus on the ability to make as much async as possible so that those precious moments where you are sync really, really matter.

What are some ways to measure success in protecting personal flow? That's another question that came through. Well, one thing you can do is take a look at people's calendars. At Asana, we've instituted no meeting Wednesdays, which means what it says. You don't schedule people on Wednesday. That is a full, unadulterated day for people to do creative work. I'll tell you what, people end up getting their most energy out of having that full Wednesday. So I think you can do a calendar audit of your whole team. Have everybody print out the last couple weeks of their calendar, stick them all up on a board, and just take a look at them together and see where you're spending your time. If there are a bunch of meetings that feel like they're kind of boring, see if you can do without them. I think the other thing you might try that might be worth noting is Slack publishes the statistics of usage inside the platform, and it's very easy to count how many emails you get and send. What if you consciously made it a goal of your team to send less, to ping each other less? I think you could really reduce the back and forth, the cost of collaboration, and reduce the meeting cost of sharing oxygen by really getting good at being async.

What are your tips for preserving quality when moving at pace? Great question, something I think about every day. Back to artifacts, really back to async. Having principles where everybody knows what's on your mind and how you're going to judge quality, articulating them and having a place that's accessible for everybody to look at, being thoughtful about what they are, making sure that they're deeply understood. That's the gift that keeps on giving. That's high leverage leadership if you're able to do that. We have design principles here at Asana, so folks who are designing our product know that the expectation is that it's going to mirror our design principles. If we see a design that doesn't, it's kind of like, what broke down here? So I think articulating the decisions that you would make, if you find yourself being repetitive, write down that thing. Write a one-page document about what you mean by X when you say X that you keep having to say over and over again. That will become part of the institutional memory of your team and be an artifact you use to onboard the next person. It becomes a very helpful scaling mechanism for you. When I run product reviews, I gave you a sense of the agendas of them. They're each different. The questions that folks know I'm going to ask just by the very nature of me publishing that, their expectations are extraordinarily clear, and I'm able to get higher quality work without the misfire back and forth. It's particularly important to know because of the design tools out there. If I see a design come in that looks high fidelity, the thinking behind it might actually be low fidelity. So getting clear on something that looks great in Figma because it uses sticker sheets and the design language system of a product, you might be fooled into thinking that you should be giving high fidelity feedback when you're really just scrimmaging ideas.

Any further advice you would have for teams that are half remote, half in the office? It's a great question because I think our future is going to look like that a little bit in the coming months. Gosh, I hope it's not the coming years, but in the coming months. There are a couple things we do. We're not back in the office fully. We have a couple of our offices globally that are back where COVID has started to recede. We do things like we have a scrum meeting or a check-in, and we're all on Zoom even if some of us are in a room together. It kind of levels the playing field. In ideations and whiteboarding sessions, we assign a buddy to each participant who's outside the room, and that buddy is ensuring that that person who's outside the room has a great experience. That means making sure the camera's in the right position, making sure that when they've got a point that it's heard. All that stuff that makes it super hard if you're kind of an advocate in the room that helps you out too.

Question here: other than Asana, what tools do you use? Well, I mentioned that we have three things that we feel are important. We use Asana for lots of things to be our plan of record of who's doing what by when. But then we also have Google Drive, we use the G Suite, we use Zoom, and we use Slack. We kind of feel like there's an emerging stack called the GASZ stack: Google, Asana, Slack, Zoom. As the best of breed new set of tools for teams that are collaborating, they work really well together. Slack and Asana have a super slick integration, for instance. We kind of built it together.

Yeah, okay, here's a good question. How do you think about the potential tension between protecting a person's flow and forcing people to use a certain set of tools to keep everyone on the same page? What you're doing if you introduce a tool is change management. You have to give folks a sense when you're leading that change that what's on the other side of the promised land is worth it. I think what that means is there's pain. You have to set the expectation that there's going to be some startup costs for everybody to learn how to use the thing. But I also think that people will see the benefits. We track our net promoter score, and we're a high net promoter score product. The comments that reflect that back to me are like, 'Oh gosh, our old system that we used to have was so much worse than having a plan of record like we have now in Asana.' When folks actually see that it's not just them who's being accountable, it's everybody else on the team, and you have a sense of how each of the individual teams work is uniquely accountable and how that accountability actually comes together, it's a beautiful thing. Folks will actually see that they're pinging each other less, they're spending less time on email. So you are taking a risk, frankly, as a leader to introduce something that's a new tool. I'll just say it. You're going to have to do some change management to get people on board. You might choose to start by having your meeting agendas and your action items or your one-on-ones in a project. But once you get over that hump as a leader, when you actually see people start checking off tasks on the project that you're responsible for, it's a beautiful thing. The nag-free task completion is a big delighter as we see it. So think about it as a change management exercise, and then people will see the benefit.

As a product person, how do you think about the time folks spend in Asana? If you do your job right, people spend less time in Asana and more time getting their work done. I think probably 85% of applications being developed are meant to attract more eyeballs and to get you to focus on their thing. At Asana, we didn't really care about that. We care more about people being in their flow time. So we make it super easy to connect up the work that you're doing right now and assign accountability to somebody else. You can see your to-do list inside of Adobe Illustrator and be doing your Illustrator work and then ticking off your list right there in Illustrator. That's how we design that integration. So yeah, I care less about people being in our UI. It's funny because we're founded by one of the co-founders of Facebook, Dustin Moskovitz, and we basically built something that is akin to Facebook in a very different way. Dustin, responsible with Mark Zuckerberg for creating the social graph, it's like the social graph is the database of the relationship between the things you click on, people have relationships with the events you attend, the things that you like, and it creates a very personalized custom view for you. Billions of people have that bespoke view. We're creating the work graph, that's the combination of what people are accountable for, the tasks that ladder up to a project, the agenda items of the agenda items and the agendas for meetings that are required to get that work done, the organization and the people who are actually doing that work. All that stuff lives together in a way that creates really bespoke views for us, for everyone else. So we're actually building the system so that it's very easy to get what you need out of it and you don't have to spend a bunch of time there. I give the Facebook example because they want to monetize eyeballs. We want to get you back to work. Similar tech backend for a very different result.

This question here: how do you balance team building meetings with so many other meetings that you already have on the calendar? I think in these times, you can't overdo it. One of those leadership lessons is that you always find yourself repeating. I think using opportunities to build teams and make people feel like they belong will get better work and better outcomes for your customers. So I don't think people do it every day. I think you could still have a morning scrum where you check in for 15 minutes for everybody, or you could just have that all happen in your plan of record, or you could do it in Slack. But having some rituals for teams and having a place where people just get to know each other, gosh, we've onboarded a couple hundred employees since the beginning of COVID. Having them feel like their heart and soul is part of a team is super important. It's not just your existing team. In a way, I sort of feel like we're drafting off the fumes of those existing relationships that we had in the office, but there's a new normal. We don't know how long those will last. So finding ways to build camaraderie, shared victories, shared norms, shared identity, that is super valuable. That's going to be the gift that keeps on giving. So it's probably not full days a week, but boy, I bet you the more time you devote to that, you'll see it pay off in big time.

This question here: what's the optimal size for your product and engineering teams? I think that's a question about ratios. I think it differs. Here's a couple examples of the differing nature of it. At Intuit, they have these notion of discovery teams which are very small, like three or four people: a designer, engineer, product manager, maybe a couple engineers, and they're on this super speedy journey to come up with hypotheses and prove them out as fast as possible, lean and mean wins. I also worked at an ad tech company called TubeMogul that was acquired by Adobe, and that is a very heavy technical platform. The ratio of the number of engineers to PM was much greater than on that discovery team. It might have been 15 operating off of a single spec, single backlog for a team, so real large leverage to a PM. Where we sit at Asana, we have about seven or eight engineers per product program, and that's with a PM and designer. Sometimes we have a more junior PM and designer being mentored by the folks on that team. They can carve off work because for an application that's front end and back end, pretty complex, there's more than enough work to feed eight engineers worth of specs and designs. That kind of team size works well for me. I think if you go lower than that, at least in our flow here at Asana, you end up with teams that are very brittle. So if somebody goes on sabbatical, somebody goes on a two-week vacation, someone just gets sick, your roadmap is at risk. So having a team that's got some resilience, some size, and you're able to weather the storm of folks being out will allow you to have more success and a roadmap that you can deliver with less drama.

There's a question here about how do you measure the productivity of product managers? Are there good quantifiable measures? I would just look at the end results. Really, if you were trying to quantify how many specs the person writes, how many meetings that person had, you're measuring the wrong thing. If you have a sense of what is the benefit they're actually delivering, like at Asana, it's like, are our teams who use Asana actually able to have less back and forth? Let's commission a study, let's measure that on behalf of users to actually see if the features that we're building manifest that. If it doesn't, what's the reason why, and how can we get on top of it? It's not about punishing failure, but taking that as what is the outcome that's customer-backed that you're solving for, and having a PM decked against that. That's the most important thing. There are other things too, like can they hire, is the team working around them engaged? I wouldn't undercount those factors, but the ultimate customer deliverable is the most important thing.

It's a question here about how often should you be checking in with your teams remotely: daily, weekly, or hourly? I think the notion of checking in with your team in itself is outdated. So I wouldn't use that mental construct. The notion of a check-in is work about work. It's the processing of the thing that you're actually doing for a set time when somebody needs to know it. That totally wrecks people's ability to focus on something. It's wasted time. So I would say operationally, you can have people type up a quick couple of bullets of what they're doing, but I wouldn't have a meeting check-in daily, gosh no, definitely not hourly. But you can check in on people a lot less if you know what they're responsible for and then you can actually see their progress in a tool to actually get the thing done. At the expense of sounding like an Asana ad, and I'm passionate about what we do, I don't have to check in on folks very often because if I want to see over my morning coffee what's going on with a particular team, I just go in and take a look. I can see it. I don't have to check in. Check-ins, I think, are part of that old form factor of work that's outdated.

Okay, there's a really nice question here from Kirsten: how do you gather, organize, and keep up with customer feedback so that you're keeping your team focused on the most common customer pains, not unique complainers? How do you do this in a way that's lean so it's not a full-time job to sort feedback? It's a great question. I'll tell you how we do it. I think it's a good practice. I think there are even ways that we can improve. There are a few places of input. Number one, customer-facing teams or feedback from the product go into a single spot called Voice of the Customer. We then are able to assign that voice of the customer to the component of the product that a product team is responsible for. So it's like, hey, the text editor in Asana is not working right. A particular person will get that, and they're responsible for reading it. Reading through customer comments every day is a great thing, you just want to have it done in a way that's scalable. But there's more than that. At Asana, we have multiple customer touch points, multiple channels. We have a sales-driven channel, we also have a real strong bottoms-up business where people check us out and swipe their credit card. We're in 170 countries, we just have a lot of different input coming in. Well, once every six months, our business teams come up with a single stack-ranked list of the most important things that they think the product team should be building, with rationale behind it. That conversation, getting that single stack-ranked list, is ridiculously clarifying. It's one of my favorite things about what we do, because then there's no jockeying, no one who's got the best relationship with the salesperson is going to influence the roadmap. It's very clear what the stack rank is, and it's based on the generation of that voice of the customer and folks being out there in the field and having a good discussion around it. The business team coming up with that thing has unique value. Then we take that voice of the customer list and we marry it up with what our product vision is. We don't just go straight down the list, but we might make a lot of progress on one, three, seven, eight, and nine. If you do seven, eight, nine, then ten comes for free. Then you also build in areas where you want to make great progress on the vision, or you build against these customer problems in a way that furthers the vision. That ends up being the roadmap chemistry that I work on with my team. But a single stack-ranked list, those are beautiful things. The last thing I'd say here is there's a lot of great feedback that comes in, and I do think if you can create a durable mental model of what you are seeing in the pattern of that feedback that you can write up on a whiteboard or make a drawing about, that is super durable. At Asana, I lead the product team, and we have product management, design, and UXR. Often UXR is folded under design, but not on our team. UXR is the voice of the customer, and they get kind of equal footing with those other two functions plus engineering. Their job isn't just to go and interview customers, it's to come up with a unique, insightful mental model of what we are learning that is understandable across the whole company. We have that for almost everything that we work on. There's a mental model of how we're approaching X, a mental model of how we're approaching Y. Those are well understood by the company, definitely well understood by the team. If you have a great mental model of what you're hearing from customers, it could be a two-by-two, or it could be the transition from this to this, or a unique view of what a pain point looks like in the market. That is the foundation, the cement on top of which you build innovation. If you don't have a great set of insights, then what are you going to do? If you have a great set of insights, it's your foundation. It makes it so much easier to build stuff right. You also then have a shared context across the whole company of what are the most important customer insights. So sorry, it's a long answer to a short question, but definitely passionate about using customer insights to drive the roadmap process.

Here's one: I noticed that in a remote world, people aren't participating as much in important conversations as they used to. What are your thoughts on that? Yeah, I map this back to a couple things. It could be an over-reliance on synchronous communication. When we were all in the same meeting rooms together, there was an expectation that you'd speak up. Zoom makes that much more difficult. So if you open up collaboration to be async by adding comments to something, by working on a document instead of hashing things out in a meeting, you might actually draw out some of that thinking. I'd recommend doing that over email. I think also the transition to video conferencing is especially exhausting for introverts. So finding alternative ways to get the great points of view is a part of leading and drawing the best out of your introverts who are exhausted by Zoom if you do a lot of synchronous work. It's a good leadership challenge. You might stop a meeting and say, in a way that's non-threatening, 'Hey, I'd really love to hear from you. I love that other point that you made in this other thing. What's your unique perspective on this?' Maybe you can tell them ahead of time that you're going to call on them to start to get more of the reflexes of people contributing in a tech that's harder to do than sharing oxygen in a room.

Last question here: I saw Asana released its future roadmap recently. What are you most excited about the potential of what you're building? Well, I'm glad you asked. We did share our roadmap publicly. If you Google 'Future of Asana,' you'll see it. First of all, it's a fun thing to do. I think we didn't share all of our secrets, but I think if you consider yourself to be a thought leader in the space, I would put some production value behind what your roadmap is so that folks can see it. That actually might be a competitive differentiator without you having to have actually built the product. If folks can see how you're thinking about the problem, there's going to be a whole bunch of people who then migrate to you. But it might not matter if you're out ahead of them from a thought leadership perspective. I'm super excited about Asana's opportunity to be more intelligent and have that intelligence manifest in a couple ways. Number one, for an individual, what if you had your own personal assistant that allowed you to make a bunch of the rote, repetitive decisions that you always make so you can do more creative work and be in flow? Number two, for teams, what if Asana showed up as your team brain so you had more shared context? It knew what you needed to know about what other folks are working on and just prompted you with that so you don't have to ping everybody. It would be that much more efficient. And three, what if Asana started to become the central nervous system of an organization? That's where the work goes on, that's how you can see how things align, that's how you can see how your resources are allocated against the most important objectives or OKRs. We just launched an OKRs product inside Asana. That's where things get really powerful. I'm harping here on clarity. Clarity is the primary way to help your teams not suffer the consequences of remote work and have more time in flow state. You can do that through tools, you can do that through clear expectations. But focusing on their flow will reap benefits for you. Well, that's it. I think we're at time. Love that you were able to join today, and good luck in your product building in these new worlds. Thank you all for your attention.