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

Okay, Alex, I'm gonna go ahead and take us live here. You'll have that few seconds delay and then I'll pass it over to you.

Can you see my video? Yep. Okay, great.

Hi everyone, welcome to SaaStr Annual. Excited to introduce our next speaker, Alex Hood, Chief Product Officer of Asana. Alex will be discussing how to build great products in a remote world. Alex, take it away.

Hi everybody, uh, thanks for joining me from wherever you are in the world. Gosh, we were supposed to do this live at SaaStr, 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 is product teams, you hire product teams to do creative work. And, um, there's a tax and the tax right now is too high. Spend 60% of our time as information workers doing work about work. And that is like trolling through email. That is getting hit up with a bunch of notifications, sitting in status meetings. It's like the work that facilitates the work, but it's not the actual thing. You know, it's not the deliverable. It's not the the spec that needs to be written or the design that's created or the code that's entered. So that said, you know, this, imagine this for 1.25 billion information workers. I mean, that is a massive, massive, massive problem and lay on top of that COVID. So, you know, 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 processes aren't that great. You know, and you probably take— you play a role in making those processes work well. And on average, we're spending 10% of our time, about 4.5 hours, duplicating work that's already been done. And I think that that's like the ro— one of the worst parts of work. I think that often ends up being like Friday, Friday afternoon, time for that status report that I have to send. And that is, that's like probably the worst part of anybody's week. 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. You know, it went to the lowest value work out there. So man, 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 want to perform to build the great things to have energy zapped. You know, this is— 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 then like 43% feels like it's holding back from advancing work. You know, fast forward to where we are now, I'd say probably it's 100%, 75%, 75%. So we're probably in the business of getting the most out of our teams that we're on or that we lead. And how do we do that? Well, here's a complicating factor. Over time, starting in 2000s up into 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. You know, collaboration is, is growing exponentially. Productivity is growing linearly, like roughly at the pace of inflation. And 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? And 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 like the back-and-forth nonsense, so that you're able to focus on building great stuff? Well, I'm gonna lay out a few, three ways to do this. And the first, very first, is having a customer focus. A lot of startups are in a situation where they feel like the founder gets to make a lot of the calls and the highly paid, highest paid person in the room gets to to have an opinion that weighs out everybody else. That might've worked when everybody was working in an office, when you were sort of like had to go to a bunch of meetings, but what's scalable? Well, scalability is teaching your product teams how to be really customer-focused because they'll be much more likely to build the right things. You know, there's vision-led companies where your teams sort of have to guess what the founder might be thinking. There's sales-led companies where you're waiting for input from sales teams as a product team is to figure out what to build and maybe even selling ahead of what gets built. There's committee-led, like the worst, right? Um, so relying on meetings to suss out what needs to get done. And then there's like customer-led and, you know, the customer-led one's probably more gratifying to work at, but then also it just must much more likely so that what you build solves a big customer problem and has product-market fit because you have the customer in mind when you built it. Well, here's the process that we use at Asana, and it's similar to other processes out there as well. It's called the Double Diamond. At Intuit, where I worked before as well, we called it Design for Delight. And it's human-centered design. IDEO helped publicize and socialize this. And it really is a couple things. Number 1, you focus on the pain before you focus on the solution. Number 2, 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 you get down to a very specific pain point for a very specific specific customer type. Only when you've agreed on that, then you go brainstorm. A lot of folks brainstorm first. That probably ends up with the worst scenario. So you go brainstorm after you've got that deep customer empathy, all that data around what the customer pain is, how it manifests. You got it pumping through your whole team's veins. And then you start to narrow on, okay, after we've done a bunch of exploration, What's the ideal customer experience? And how do we work backwards from that? It's like the Eric Ries methodology. So you narrow then 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. Then 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 if 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 doing a series of design reviews into launch review. And me, from a perspective of now managing remotely, man, if we're all on the same page of what the process is, what the checkpoints are, and then what's expected of the checkpoints, it makes the team's life better, it makes your life better, and there's much less back and forth and work about work to build a great product. Um, this is Asana. It's, um, the system that we build but we also use to build product. And you'll see here in Asana, um, uh, Asana is kind of like the plan of record of who's doing what by when for all the projects that happen in a company. Um, here is our product toolkit, which maps exactly to these checkpoints. And basically what we've done is 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. And then inside Asana, there's key questions, basically like 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 it, know what the rigor is expected of them, instead of like laboring over some new framework that they're building themselves. Themselves. So it's like clarity of expectations is really, really helpful. So that was really around, um, of, of being customer-centric and how we do it at Sun. The second piece though is like, what's the— what are the tools that you use? And 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? Now, there's a big exception that Google really popularized getting those form factors in the cloud, still exist 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 as it could. So at Asana, we feel like great teams have 3 things. They've got a place where their content lives. That's important. You got a place where communications live, like messaging, Slack, email, Zoom. All those things are important. And there's also like a coordination layer. That's the who's doing what by when, who's accountable. We really believe that you do your best work, 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 gonna have more fun at work if you know how your work ladders up to something greater. And that's kind of what the coordination or work management does. So if you haven't checked out something like Sodding, you might want to. You know, so, um, you know, here is a— this is a project in Asana. It's a big cross-functional project for a community mobile app launch, and product marketers and engineers, they all contributed to it. And you can really see how all the pieces come together. And then you can pivot that same project into a Kanban. You can plan right to left in a, you know, a Gantt or timeline view. All this uses the same underlying data. So you'll click on one of these tasks, use the same task as one of these cards. It's just presented in a different way. So you might want to get yourself a planner record, you know, that I think if you invested in that, you'd find yourself with a lot less, a lot fewer pings. You also might wake up— if you're like me, sometimes you wake up early in the morning, you're like, oh man, what's going on with that thing? And the dangerous thing is you go and you ping a bunch of your colleagues. And then they wake up to anxiety because, like, 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, saves them, saves your teammates anxiety. It also just builds trust. So that's the second piece here. You know, I started with Being customer-centric is a scaling opportunity, and it allows for 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 2, the toolkit. If you had a toolkit of what the plan of record is, then, like, you don't have to say goodbye to the latest plan of record in Slack or in Teams when, like, GIFs get added to a work stream and you're like, "Oh no, like, I'll never find where we agreed the plan of record." ever, ever, ever, ever again. Lastly though, I think that there's something here around protecting the focus of your team. You know, back to that 60% of time that we spend on work about work. I spend all my time trying to hire really awesome product people, designers and engineers, product managers and researchers to do their craft, to do the thing that they're passionate about, to innovate and come up with something amazing that customers will love, or come up with some great new learning. And if you tax them to work about work, or lack of priorities, 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. You know, we do this in Asana by, you can like public your, we're building capability. We can publish your intention of what you're doing. People are less likely to then ping you. There are other tools that do that as well. Also just have like really great one-to-ones. One-to-ones make a huge difference. So if you've got a place where you've got your agendas for your one-to-ones already created, you can look at them together. That makes a big difference. If your one-to-ones can be productive, if you have one-to-ones, gosh, I mean, you really need to if you don't. Those who have one-to-ones are 3 times more likely to stay at their job. They're twice as likely to be engaged. So like taking that time to get synced, have that like Martian mind meld, share oxygen, super, super important. That takes a lot of the back and forth out of collaboration in many tools. You can just like see eye to eye and that will just save a bunch of time later. Well, 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 this space. And here's the big aha. There are things that drive individual performance here. I'll list them here. Clarity of knowing who's doing what, why it's important, knowing how the thing that you're doing contributes up to something greater, getting rewarded for your great work, and knowing how well you're doing along the way, and then being free from distractions. Those are the drivers of individual high performance. Employee engagement. That's something— if you're— you might be at a company that measures that if you work at a larger company. And it's something that is measured and tracked over time, 'cause it's a best practice to survey your team, see how, see how they're doing. And the companies who are to do this best, well, they have basically narrowed down the things that drive high, high-performing organizations that are highly engaged. Highly engaged and high-performing are kind of the same thing. Number 1, recognition for high, high performers. Number 2, have a very If everybody has a clear sense of the strategy, it's very well communicated. Uh, number 3, um, everybody can see how their personal work aligns to something bigger. And you may notice that there's some redundancy in what I just said, 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, of the work that matters most. And then like reducing the nonsense so that you can actually get work done. So it's great for individuals to maximize their time. It's also just going to lead to better outcomes as an, as an organization. So say this as a long story to say that like actually protecting your time and maximizing the things that drive the focus of your team the flow, clarity, reward system, freedom of distractions, makes a big difference to overall organizational results. And, um, 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. And I think that there's kind of like 3 phases of servant leadership. And I challenge you to, to really consider the third phase. The first phase is like, hey, making sure your team's unblocked. Like if there are decisions that they're stuck on, they're not just like, spin, spin their wheels. I think that then the second phase of servant leadership is like celebrating failures. You want your, you want your folks to work on bold initiatives, to innovate, to experiment, to be creative, you know, have creative safety in their work. And one way you do that is you be hypothesis-driven, you allow experimentation to occur, and you celebrate failures. You know, those two things are pretty, I think, 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 these people who these folks report to. But 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 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 it's like parents are trying to figure out how to get their kids back on Zoom, or they're like half childcare, half coding, or they're dealing with like the loneliness of COVID and it's harder to stay focused. Um, or maybe they haven't been in their career that long. And, um, they get easily distracted. Maybe there's that Zoom exhaustion. Well, protecting that focus and flow time. When I say flow time, I mean, like, you've all felt it. Like, it's that time where time passes by really, really fast. You're really deeply ingrained in your work. That's what you really want your folks to do. And 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. Yeah, those are the points I wanted to share. When I just 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'll be less drama along the way. There'll actually be less back and forth. Number 2, you have a toolkit where accountability lists, 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 focus time of your folks and make sure that they're intentional with the use of that time as well. You know, if you can take that 60% of work about work time or not get back to 40%, man, what a service you've done to your team. You've given them a whole day to create, to innovate, and that's what you really want. So that's my two cents on building products remotely, and I'm more, 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 I was the PM, and the engineers were that far away. I'll tell you what, you're not 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. And then they can see your response. Such a waste of time. I mean, talk about work about work that happens in hours and not minutes. So I think really getting clear on like, artifacts that can be consumed async. Get clear with your team on what can be done, either by taking a look at a document and commenting on it using something like Asana, having a ticketing system, or do more written and hire people who are great writers and 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, 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— this happens to be a meeting for me, but you don't schedule people on Wednesday. That is a full, unadulterated day for people to do creative work. And 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. You have everybody print out the last couple weeks of your 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's a bunch of, if there's a bunch of meetings that feel like they're kind of boring, nix them. See if you can do without them. I think the other thing you're trying to do that might be worth noting is like, 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. [Speaker:JASON M. LEMKIN] Let's see here. 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. Principles where everybody knows what's on your mind and how you're going to judge quality, articulating them and having them placed 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, They know that like, this is the expectation is that it's going to mirror our design principles. And if we see a design that doesn't, it's kind of like, well, what broke down here? So I think articulating the decisions that you'd make, if you find yourself repeating, 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. and that will become part of the institutional memory of your team. It'll be an artifact that you use to onboard the next person. And it becomes a very, very helpful, another great scaling mechanism for you. So, you know, I showed you when I run product reviews, I kind of gave you a sense of like, these are the agendas of them and they, they're each different. The questions that folks know I'm going to ask, just by the very nature of me publishing that, there's, 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 design, the design tools out there. If I see a design come in that looks high fidelity, thinking behind it might actually be low fidelity. So getting clear on something that looks great in Figma, because it's been using— 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, you know, our future is going to look like that a little bit in the, in the coming months. Gosh, I hope it's not the coming years, but in the coming months. There's a couple of 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 Scrum, 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 as well, 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. So that means making sure the camera's in the right position, making sure that when they've got a point that it's heard, um, you know, 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 is, other than Asana, what tools do you use? Well, yeah, I mentioned that we have 3, 3 things that we feel like are important. Use Asana for lots of things to be like 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 GAS stack, G-A-S-Z, so 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, we built it together. Um, just taking a scan of some more questions here. Yeah. Okay. Here's a good question. Hey, um, 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 you're doing change management, and you have to, you know, give folks a sense when you're leading that change that what's on the other side of the promised land is worth it. And I think what that means is, is There's pain. You have to sort of 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 you can't— people will see the benefits. And we're— I track our Net Promoter Score, and we're a high Net Promoter Score product. And it happens— the comments that you read that reflect that back to me are like, oh gosh, like our old system that we used to have, you know, 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. Um, because folks will actually see that they're pinging each other less. Um, 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. Um, and you're going to have to do some change management to get people on board. You might choose like, hey, let's just start by having our meeting agendas and our action items or our one-to-ones in a project. Um, but once you get over that hump as a leader, man, when you, you actually see people start checking off tasks, on the, on the project that you're responsible for is a beautiful thing. The, the nag-free task completion is a big delighter as we see it. So, um, think about it as a change management exercise and, um, then people will see the benefit. All right, looking through some more questions here. 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. Yep, I think, um, probably 85% of applications being developed there are meant to attract more eyeballs and to get you to focus on their thing. And at Asana, we don't really care about that. We care more about people being in their flow time. So we make it like super easy to connect up the work that you're doing right now and assign accountability to somebody else. Like, you can basically like assign— you can see your to-do list inside of Adobe Illustrator and be doing your Illustrator work and then ticking off your list write straight up in Illustrator. That's how we designed 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, we basically built something that is akin to Facebook in a very different way. Dustin is responsible with Mark Zuckerberg creating the social graph. It's like the social graph is the database, the relationship between things you click on, people you have relationships with, uh, the, the events you attend, the things that you like. And that creates a very personalized custom view for you of that billions of people have that are bespoke. We're creating the work graph. That's a combination of what people are accountable for, the tasks that ladder up to a project, The agenda items of the agenda items in the agendas for meetings that are required to get that work done. The, 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 everyone else, for everybody. So we're actually building the system so that it's very easy to get what you need out of it, and you 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. Um, similar tech backend for a very different result. Question here of how do you balance team building meetings with so many other meetings that you already have on the calendar? I think at the time, in the, in these times, um, you can't overdo it. You know, you can't overdo it. One of those leadership lessons is like, you always find yourself repeating, you find, you find yourself repeating yourself. I think, you know, using opportunities to build, build teams and make people feel like they belong will get better work, get better outcomes for your customers. So I don't think people do it every day. I think like you, you could still have a morning scrum where you check in for feedback. 15 minutes for everybody. Or you could just have that all happen in your plan of record, or you could have it— you can 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, we've onboarded a couple hundred employees since the beginning of COVID and having them feel like their heart and soul is part of a team is something 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 from that we had in the office, but there's a new normal. We don't know how long it was going to last. So finding ways to build camaraderie, shared victories, shared norms, shared identity, that is super valuable. I mean, that's just going to be the gift that keeps on giving, frankly. So, um, you know, 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. Um, this question here of what's the optimal size for your product and eng teams? I think that's a question about, um, ratios. And I think it differs. Here's a couple examples of the differing nature of it. At Intuit, Intuit has these notions of discovery teams, which are very, very small, like 3, 4 people, 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. In a way that's 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. And the ratio of the number of engineers to PM was much greater than on that discovery team. It might have been a dozen, 15, um, operating off of single spec, single backlog for a team. So real large leverage to a PM. Um, and then where we sit at Asana is we have about, about 7 or 8 engineers per product, product program. Um, and that's with a PM and designer. Sometimes we have a, um, a more junior PM and designer be mentored by folks on that team that 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 8 engineers' worth of specs and designs. So that kind of team size works well for me. I think if you go lower than that, at least in our kind of flow here to Asana, you end up with teams that are very brittle. So somebody goes on sabbatical, somebody goes on a 2-week vacation, um, somebody just gets sick, your, your roadmap is at risk. So having a team that's got some resilience, it's got some size, and you're able to weather the storm of folks being out, will allow you to have more success and a more, um, a roadmap that you can deliver with less drama. All right. I am looking through some questions here, some great questions. Thanks for asking them. Um, there's a question here about how do you measure the productivity of product managers? Are there good quantifiable measures? Um, I would just look at the end results, really. I think if you were trying to quantify how many specs did the person write, how many meetings did that person have, sort of measuring the wrong thing. If you have a sense of what is the benefit they're actually delivering, like in Asana land, it's like, are teams who use Asana actually able to have less back and forth? Let's commission a study. Let's, let's measure that on behalf of users to actually see if the features that we're building manifest that. And if it doesn't, what's the reason why? And how can we get on top of it? So it's not like punishing failure, but taking that as like, 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's other things too, like, can they hire? Um, is the team working around them engaged? I wouldn't undercount those factors, but the ultimate customer deliverable is the most important thing. [Speaker:JASON M. LEMKIN] There'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, is the processing of the thing that you're actually doing for a set time when somebody needs to know it. That's like totally wrecks people's ability to focus on something. It's wasted time. So I would say like operationally, you can, you can have people like type up a quick couple of bullets of what they're doing. Um, but I wouldn't like have a meeting check-in daily. Gosh, no, definitely not hourly. But you can, 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. And, you know, at the, at the, um, expense of sounding like an Asana ad, and I'm passionate about what we do, I, I don't have to like check in on folks very often involved. Cause if I, if I want to see my morning coffee, like what's going on with a particular team, I just go in and take a look and I can see it. I don't have to check in. Check-ins, I think check-ins are part of that old form factor of work that's outdated. All right. See here, lots of great questions. 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 don't— I think it's a good practice. I think there are even ways that we can improve. There's a few, there's a few places of input. Number one is customer-facing teams or feedback from the product all go into a single spot called Voice of the Customer. And 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 if it's a like, hey, the text editor in Asana is not working right, you know, 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 do it in a way that's scalable. But there's more than that. There's been a— at Asana, we have multiple customer touchpoints. We have multiple channels. We have like a sales-driven channel. We also have a real strong bottoms-up business where people check us out and swipe their credit card. We have different— we're in, we're in 170 countries. We just have a lot of different input coming in. Well, once every 6 months, our business teams come up with a single-stack ranked list of the most important things that they think that the product team should be building. With rationale behind it. And that conversation, getting that single stack rank list is ridiculously clarifying. It's one of my favorite things about what we do, because then there's no jockeying, there's no real, you know, who's got the best relationship with the salesperson, salesperson's going to influence a roadmap. It's very clear what the stack rank is. Um, 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. Like the, the business team coming up with that thing has unique value. And then we take that voice of the customer list and we then marry it up with our— what our product vision is. We don't just go straight down the list, but we might do— we'll make a lot of progress on 1, 3, 7, 8, and 9. And if you do 7, 8, 9, then 10 comes for free. Then you also, you know, build in areas of there 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 single stack ranked lists, those are beautiful things. 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. We at Asana, I lead the product team and we have product management, design, and UXR. And often UXR is folded under design. 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. Um, and their job isn't to just go and interview customers. It is to come up with a unique, insightful mental model of what we are learning that is understandable across the whole company. And we have that for almost everything that we work on. There's a mental model of how we're approaching X, mental model of how we're approaching Y. Um, and those are well understood by the company. They're definitely well understood by the team. And if you have a great mental model of what you're hearing from customers, It could be a 2x2, or it could be the transition is from, from this to this, or a unique view of how, what a pain point looks like in the market. That is the foundation, the cement on top of which you build innovation. You don't have a great set of insights, then what are you going to do? You have a great set of insights as your foundation, man, it makes it 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, um, real large. So, sorry, it's a long answer to a short question, but definitely passionate about using customer insights to drive the roadmap process. Let's see here, um, I think maybe we have time for one or two more questions. Here's one. I noticed that in a remote world, people aren't participating as much in important conversations as much as they used to. What are your thoughts on that? Yeah, I map this back to a couple things. Um, it could be an overreliance on synchronous communication. So like, yeah, if it was super— when we are all paid to be in meetings in the same meeting rooms together for an hour, and, um, there's an expectation that you'd speak up there, Zoom makes that, 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'm going to recommend doing that over email. Um, I think also just like the transition to video conferencing. Um, I think it's an, it's ex— especially exhausting for introverts. So finding alternative ways to get the great points of view is a, you know, uh, part of leading and drawing the best out of your introverts who are exhausted by Zoom. If you do a lot of synchronous work, um, is a good leadership challenge. So you might stop a meeting and say, you know, in a way that's non-threatening, like, hey, I'd really love to hear from you, man. I just love that other point that you made in this other thing. What's your unique perspective on this? Maybe even tell them ahead of time that you're going to team up, start to get more of the reflexes. Of people contributing in a tech that's harder to do it than sharing oxygen in a room. Last question here is, 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. Yeah, we did share our roadmap publicly. It's, if you Google future of Asana, you'll see it. First of all, it's a fun thing to do that. 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, what, 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 me too you, but it might not matter if you're out ahead of them from a thought leadership perspective. I'm super excited about Sana's opportunity to, um, take on be intelligent and have that intelligent manifest in a couple of ways. Number one, for an individual, what if you had your own personal assistant that allowed you, that made 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, how, 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 didn't have to paying everybody, be that much more efficient. And then 3, what if, what if Asana started to become the, you know, the central nervous system of an organization? So like, 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. And 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're able to join today, and good luck in your product building in these new worlds. And thank you all for your attention.