Cloud-first Clarity: Evolving Infrastructure for Enterprise Clients with Asana head of Engineering

Sana, and we will be joining us for this interactive roundtable for the next 35 or so minutes. We will be discussing Cloud First Clarity: Evolving Infrastructure for Enterprise Customers. And then before we get kicked off, just a few housekeeping notes that we need to get through. So to submit a comment, response or question to the speaker, you can use the Zoom chat in the bottom toolbar of your screen. If you'd like to speak directly to the speaker, please make sure your camera is on, and then you can raise your hand and unmute yourself appropriately. This will be an interactive 35-minute session, and we encourage you to keep your camera on and audio muted for the remainder of that beginning portion. And these sessions will be recorded and available after the event. And with that, take it away.

Hey, I'm excited to be here and looking forward to the conversation. We'll see how this roundtable format goes. I'll be trying to get some of your comments and inputs in as we, as we go along. So as far as how we'll go through the topics, I'm gonna be talking about enterprise support, what experiences I've built up over the past 7 years at Asana, and I was at AWS building DynamoDB before that. So I'll talk through some of my learning about building for large customers. And I know we'll have participants with varied experiences, so your input is welcome as we go along. Dealing with a lot of Windows and technology here, so we'll see how this actually plays out. And we'll also have space for discussion in the end. So as you can see on the agenda, the, the areas that I'm interested in talking about are first building infrastructure for security and reliability, creating consistency and controls for admins, building data isolation, and connecting customer data with other products that your customers use. Moving along here. When we think about infrastructure and we think about reliability, having strong security controls and high uptime is key for customer trust. There is an overlap in requirements that comes with high scale, and there are also specific requirements that come in because of enterprise customers. I won't, for this particular segment, I won't try to differentiate a lot between those. If you are building for enterprise, you have to deal with both of those anyway. So in terms of, I expect that you are from different stages in your journey thinking about customer size. And so when it comes to security and reliability, My answer to the question of when is the right— when is it the right time to focus on these is pretty much all the time, including when you're just starting out. The way I see it, if you're building SaaS, odds are that you'll be holding very important customer data. And regardless of what you build, if your customers are using you, you are a threat vector for attacks on your customers. We've seen a bunch of that in recent months and years, and I don't expect that to stop. So given the stakes, I believe we have an ethical and moral obligation to ensure that our systems and practices meet and exceed any claim that we make about security and reliability to our customers. So wanna give you a few examples of things that we've built and been asked to build over time as we have talked to larger customers, service larger customers. One of them is formal SLAs around uptime. Of course, you are building for high availability. If you're building SaaS software, people expect it to be available at all times. But as you talk to more customers who are using you for mission-critical type applications, you will see formal SLAs show up in contracts. And the exact terms will obviously be a business decision, but you'll need, as you're building infrastructure, as you're building the product layers, You need to be confident in your uptime, and you also need the ability to measure uptime, and you need the ability to probably measure uptime on a per-customer basis, so you know that you're meeting your contractual obligations. So these are some of the things that kind of escalate over time in terms of what your capabilities need to be. Another important piece is customer-visible real-time status of your platform. And this has become more and more table stakes as customers adopt SaaS. They expect to be able to see what has historically been your uptime, when you've had events, and then communication about events and incidents as they are happening is also something that is just your best practice in my mind, and also something that is becoming more common and table stakes. And so I think that putting these in early is important. And as you mature and have more specialization, creating this visibility for customers also drives more collaboration between your customer ops teams and infrastructure and tech ops teams. And I think that's a good thing to have those communication channels. So you are both getting visibility into how customers are experiencing a particular degradation in your service or outage, and also for you to be able to communicate back what you found so far, what your ETA is, etc. Another aspect is backups. Of course, if you're a technologist, backups are just a tool in your toolkit for increasing reliability and durability. As you grow, be prepared for customer expectations around backups. You probably start off thinking of backups mostly as how long does it take us to recover the whole application? But as you run into larger customers, you will hear requirements around backup periodicity, location of your backups, Retention, are you holding onto that data too long, et cetera. So you'll hear all of these. So building flexibility around how you do your backups and how you manage your backups is pretty important. And another thing that over time we started to do is not just have the design that knows how to recover from backups, but actually put that into practice. And test out our ability to recover just from backups. Can I ask a question? Yeah, sure.

When do you start thinking, because we're talking about security, right? Like about like things like that are a little more like table stakes, like SOC 2, some of those like things that are more on the compliance side.

So yeah, we'll talk a little more about compliance later as well, but overall I think it, It is very much dependent on your customer set and the, as well as the type of application you're building. If the things that you are trying to replace already have compliance as table stakes and everybody has it and you will not even get your first customer trial, you have to build it even before your first customer tries you out. For Asana specifically, I think we probably were well into tens of millions of dollars business before we did SOC 2 Type 2. So we had more of a runway before we had to do that. And we've recently done ISO 27001. K, which is more as, as our European customers have become larger, that's become more of a requirement. We are actively looking at more vertical ones related to government or finance or healthcare. And it just depends on your customer set, which of these you will prioritize. Couple of thoughts here. One is I think that when you do compliance, my advice is don't just check boxes and try to say we are compliant with X. Actually build in the controls because the, the spirit behind that compliance is good one. It actually increases your security if you build in the right controls while building compliance. And second is consider ongoing costs, not just What does it take for us to get compliant on X? But then what does this mean for our engineering culture? And what does it mean for ongoing maintenance of that certification? So you might add certification that, for example, requires 3 levels of review before any of your code can go to production. Hypothetically, and that might be pretty easy to get that checkbox saying, okay, we implemented that control, but you might be forever then slowing down your development velocity. So definitely a consideration as we, as we think about compliance, and that's something we evaluate. Value that we'll get from getting a particular certification cost of getting it and ongoing maintenance for it. Cool. So in terms of, yeah, going further into this, so cloud infrastructure providers provide great tools to manage encryption. So definitely something that should be on your mind and something you should be actively working towards. And in many cases, it is just a question of turning on a configuration in AWS or GCP to get encryption in place. Again, my recommendation is to think about your encryption strategy holistically, How is your data encrypted at rest? How is it encrypted between services? What's the granularity of encryption that you're using, et cetera? And yeah, one important thing to mention, again, as technologists, it's easy to focus on the design and architecture and infrastructure of your application, but things like office network and physical security are just as important as you think about overall your security. And when the first customer questions and expectations around our Office security came in, I was surprised to hear customers care about it, but now I ask our vendors the same question. So it is because it's such a big threat. So it's pretty important to start thinking about these and have active plans because they're important to protect your data and your customers' data. If folks have thoughts about efforts related to security and reliability, I'd be happy to hear those before we move on. All right, I will, I will move on, but feel free to chime in on chat as well. So talking a bit about admin controls, So many, many SaaS products like Asana are built for adoption directly by teams. They don't require IT to install and manage. However, as your product gains traction, IT becomes an important stakeholder in how your product is used inside the customer shop. And the needs of IT will vary by geography, by vertical, and there'll be customer-specific needs and requirements. So just to give you some examples of things that we've built for our IT user segment, user management, basic deprovisioning, provisioning, but then for larger customers, more grouping of customer, more grouping of users and roles. What active integrations are present and what are allowed is another thing that you'll want to build controls for. So you might have an integration and you might be very excited about it, but some of your customers might be much less excited about that particular integration. They don't want TikTok videos to appear directly in your product and they might want to shut that off. So giving— launch away, launch your integrations, but give admins control. On what can happen. Privacy, security settings, data export, all these are things that might not be in your initial product requirements, but as you start thinking more about IT, they should become part of your requirements. Can I—

I'm going to ask, I'm going to dig in here if that's okay. Yeah, I find this— so Asana, I think from the beginning, right, you guys built for the team.

Right? Yeah.

Like you did both. I know a lot of SaaS companies, especially now with product like Growth, they build for the individual and then they get roped into bigger deals, more team, more user management. Right. Um, what, like, what suggestion do you have if you're in the latter, if you're not as lucky as Asana, you're not as forward-thinking, you, you didn't think about like that flexibility from day one, right? Like, we're like, what recommendation do you have for those folks?

Start now.

Okay.

That would be my recommendation is you are where you are and sounds like you have, sounds like you have traction, sounds like you have those individual users. So at this point, start thinking about what it will take and it is a journey and you can bring your customers along. I'll bring it back to this as I wrap up actually. So let's move on and then come back to this. So one thing I think about a lot and have continued to is data isolation. And basically SaaS, one of the key things that makes SaaS attractive other than removing the operational burden from your customers is multi-tenancy because it makes, makes your offering more efficient. And as your customers become larger, there actually is an opportunity to isolate customer data without giving up on efficiency. And with isolation, I mean, you, you provide more scalability, performance, security for individual customers by putting their data in compartments you can reduce noisy neighbor problems for performance, for example, and make customers feel more warm and fuzzy about your architecture because they can see that their data is protected, maybe on a different disk, on a different database, with a different encryption key. There are various ways of isolating different customers' data. But all of those tools are helpful in providing isolation for one customer versus another. We've been on a long journey as we've built out our application layers. One of the interesting things— I won't go into details on this picture, But one of the things that we were able to do because we had data isolation between customers is provide the ability for customers to place their data, for example, in an EU data center as opposed to in the US. So that was a strong requirement from some of our European customers. And— but building that out even while having data isolation wasn't trivial because we had to join data in some cases with a centralized database. And in those cases, what, so what we had to do was built out a service instead of a direct data store join, we had to build out a service that provides membership information cross-region. So these are the kind of things that you will have to do as you mature from full multi-tenancy architecture, built around providing layering to isolate customer data, to actually separating out the customer data more vertically across your layers. And the final piece is connecting data. And what I mean by this is thinking about how your customers are using not just your product and application, but actually what is the ecosystem of products that you're— oops. Yeah, what's the full ecosystem of products that they're using? And so according to Asana's Anatomy of Work survey and index, on average workers switch between 10 different applications And they're actually doing the switch 25+ times a day. And I think that's actually an underestimate when we talk to people. I probably switch between applications more than 25 times. And so enterprises are dealing with thousands of applications that employees want to use. So connecting your app and connecting your product to other applications allows the value that you're adding to be more accessible through more services. So build an API early, start thinking about your developer ecosystem so that you are, you are helping others build on top of your product, not building each of these integrations out yourself. And as you think about enterprise, there will be specific security needs. So SIEM, audit logs, DLP, loss prevention basically, are important tools for customers to secure their usage of your product. So I'll go to my key takeaways as I've thought about enterprise broadly, and then we can have more of a discussion. So One of the first things is to have empathy for your customers broadly, but specifically for your large customers. The IT folks you are working with, the buyers, all have an obligation to protect their data. And when they are thinking about the value your product is adding, they're also looking to control and protect their data and minimize risk while getting the value that you offer. My experience is that they are opinionated about their needs because they— you're not the first vendor that they're dealing with. But in many cases, and in most cases, they're often willing to discuss how their goals could be met if you are able to find the right people within those organizations to have those conversations with, I highly recommend having— starting with what is the problem you're trying to solve, and then how can our product change, or how you can use existing capabilities to minimize the risk that you perceive. The second thing is that Even though admin use cases are a much narrower set usually for products than the product that you're building overall, they are customers. They are using your product directly. And to have the right experience for enterprise, it pays to treat admins like first-class customers, do user research, understand their workflows, and build to provide, to make their customer experience as smooth as the customer experience of your, the functional elements of your application or of your product. And the last piece is that for any company, you're dealing with hundreds of things that you could be building. It's hard to prioritize asks from your larger— largest customers along with the rest of your roadmap. So it feels like you have to leave one behind. One rule of thumb that we've developed is basically that we will listen to customers, we will reorder our roadmap to prioritize things if we are getting strong input from customers, but we won't build one-off features that nobody will use for any particular customer. We'll only build things that we think are on the roadmap. They are the right thing to build for us, for our product, for many customers, not, not individual kind of solutions. And we've, we found us, we found that our largest customers are usually just the tip of the iceberg. They are pulling us in a direction, but it's not for an individual use case. Those needs actually show up in many future engagements. So we might say no once, but by the third time we hear it, we're like, okay, this is a trend. Let's talk about it and let's maybe rework our plans to build this in early. So those are my main takeaways, and I'm happy to switch to questions and your thoughts about what you've experienced as you build for enterprise.

Awesome. Just a reminder that you can ask questions in the chat, or you can raise your hand, unmute yourself, jump in on the conversation.

Any other questions or any, any battle stories to share? Happy with either.

How do you prioritize which ones to tackle when you're resource constrained, right? Let's assume you're a 10, 15, 20 person startup, right? You know you should do security, you know you should do SOC 2, you should do team management, build for the admin, But at the end of the day, right, you have maybe 2, 3 engineers. Like how do you know which one to like do this quarter, next month versus 2 years from now?

Yeah, I mean, this is— it's not an easy question. It's something that we grapple with at our scale and have grappled with when we were at the stage you're talking about as well. So it's a journey. I think there's a couple of things to think about. One is existential risk, right? If you— there are ways in which you could lose customer data which would just end you as a company. And so thinking through how can we leverage the security offerings maybe of our cloud provider, how can we get help, use the resources that maybe your cloud provider provides. They might have Solutions Architect, architects that can help you validate that the way you're building doesn't have massive holes right at the beginning, right? You're building right from the beginning, but you don't need a dedicated security effort on day one. Finding product market fit is probably way more important than that. Um, and I, I think the most painful discussion decisions come down to This could be the largest customer we've ever had. And that number, the dollar value associated with that keeps growing as you grow. So it's not like that decision becomes any less painful as you grow bigger. And you just have to know when to say no as well. And you have to learn how to say yes and get to yes with the customer. And you have less leverage when you're smaller and maybe a little more, but not a lot more as you get bigger. And one other interesting thing is that the largest customers, when you— when they are writing you 6-figure, 7-figure checks, they really want to test out whether you will be a strong partner with them. So some of their asks might be ways to see how you engage with it, and they might be very willing to negotiate on timelines of delivery. So I think engaging with the spirit of what we call co-creation is important, where you and your customer working together saying, okay, clearly you see value in our product. Clearly you have needs that we don't meet yet. What can we do so that you're comfortable with the usage? And that might be on their end specifying what usage is allowed right now and what they will unlock if you do XYZ things. So that there's multiple ways to go after it, but it's not— it's a very nuanced decision usually, and it's hard to say no, but you should sometimes.

Awesome, thank you for that. We have time, I think, for about one more or so questions. So if you have some questions, feel free to drop them in the chat. What do you think is one of the most common misconceptions about building for enterprise?

It's a good question. I definitely haven't done a survey to know what this might be. But I think the— it might be that one of the misconceptions is that if you're building for enterprises, you are building point solutions for individual customers and you essentially need to have a service component where you are just customizing your application multiple times, once for each customer. I think modern SaaS is much more, uh, deploy in any customer. And I, I think that is the holy grail for, for achieving true scale. Um, some applications might definitely be more suited for deeper customization. But I think for most companies, I would advise at least thinking, what is the problem this company is trying to solve, this customer is trying to solve with their ask? How does that overlap with similar concerns that other large customers will have? And how can we solve this problem that doesn't just solve it as a custom solution for one customer, but solves it broadly for a set of customers? I think you'll build a more scalable business if you think that way.

What a great answer. If there are no other last-minute questions, final moment.

This is great. Thank you.

Awesome. All right. Thank you so much, Prashant. This has been amazing and such a great session. We have a lot more great content today, and I will see you all in the next session.

Thank you.