5 Insights for Consumerization of the Enterprise With Scott Belsky, CPO of Adobe

Because we're all people would want to do their day to day work with all these various tools. And then by doing that then you can actually find a wedge that you want to get into providing your own service and then deepening the customer relationship and the stickiness from there. I think a great example of this there are many, but one is charthop. They are enabling you to work with a number of different underlying APIs in the HR tech space. And their kind of wedge in is being the source of truth for your directory and kind of managing Org charts and knowing who reports to who and what organization everyone is in. And then before you know it, maybe you actually start to use a few more of their kind of first party services as opposed to those underneath the surface. And so I do believe that the surfaces are becoming more important and in some ways threatening the providers of the services underneath. And that's just a reminder that the choices that we ultimately make in our day to day lives, both as consumers as well as workers within the enterprise, are made at the surface or the front end of everything. And I mean look at Tableau, look at. There's so many other products right now that are in the surface business and that's a very. Yeah, that's a very kind of destructive space to be, I believe. And another reason for that is just the tolerance or the lack thereof within the enterprise these days for a number of different things. There's less tolerance and willingness to learn how to use products. The expectation for elegance and simplicity is suddenly really high. Whereas before you just kind of use the products you were told to use, now I think people are becoming more confident in the enterprise and vocalizing their displeasure with the user experience of the tools that they're given. I think this is being driven partly by just the higher bar we have in our personal lives. It's being driven by the confluence of some products that we use for both personal and work purposes. And also this bottoms up adoption motion in the enterprise that is sort of empowering people to say here, hey, why do I have to use this clunky thing when so and so over there is using their corporate credit card and has a far superior surface to interact with on a daily basis. And I think it's a really exciting trend because this is one of the themes of this presentation will be the power of design and empowering design to have a seat at the table for enterprise, for enterprise products. I would go as far as to say that design is starting to commoditize tech. And I wrote an article a while back called the interface layer. And this observation that a lot of industries are playing this kind of slap a hand game where whatever interface at the top is at the top has the most power. And if you think about winning that interface war, it's really the design and the user experience that is most compelling. And I also think that on the sales side, again, I mean if it's a bottoms up adoption model, people are voting with their happiness in terms of whether they want to adopt and start using the product or not. And this top down mandated sell, as we all know, that motion of sales is becoming a little threatened by some of these more bottoms up approaches. And I think, I think just design is an important role there. When I say it's commoditizing tech, what I mean by that is that there are just more and more options of underlying APIs, but then also reuse of code. And I think that when you're building these applications, there's just so many now components that are readily available or open source on the market that you can cobble together to build the underlying kind of frameworks and services. And it's really starting to be the design that is further differentiating some of these products out there. I'll put it that way. Another thing that I just would put in this category of simplicity and how you should be thinking of your enterprise interfaces as consumer interfaces is also just the use of game mechanics for people utilizing products in the enterprise and really making sure that when you're driving adoption, you're thinking about some of the things that drive people to find the usefulness of a product. Back in. My first observation of this in my career was really right out of college, 2000, 2001, 2002 timeframe. I was working at Goldman Sachs and cutting my teeth in business, I guess you could say. And I was working in an area, I was kind of like a trading floor. And they put in these brand new, very expensive phone terminals and the system for people getting on these virtual conferences as opposed to gathering in rooms. It was just more effective for everyone to just be in a virtual audio conference essentially in real time to discuss anything that was happening in the market. And nobody was using this technology, this expensive installation. And then people were told to go to training, they would get emails, no one cared about this stuff. And then suddenly one day some funny person on the floor stood up and was like, everyone con one. People were like, con one. What does that even mean? Of course people realize, oh, there's this little conference one button, like I'm gonna jump into that room, and then he told a joke in there. And then suddenly other people started to use these rooms to tell jokes and just do funny things. And before you know it, they were being used for business purposes. I think Slack is another example. My team, when Slack first emerged, we were using one of Atlassian's products, Hipchat. I think it was to have our team chat rooms and stuff. And no one had any interest in switching over to a new product until someone said, oh, wow, there's animated gifs in this and you can do some funny things with the channels and the bots. And before you knew it, people were using that as their kind of coffee room. Hey, I'm going out for coffee, I don't want to come with me. And then of course, fast forward a few weeks and suddenly the team has moved on and adopted this new enterprise technology. And so I think there's a message here around novelty preceding utility increasingly in enterprise product adoption. And it's weird because when we're building the specs for products, especially an enterprise SaaS product, the last thing you're doing is thinking about, you know, games and novelty and mechanics. Except that's actually the first thing you do when you're building consumer products. You have to get people engaged and get that firewall going. And so I think this is one of those practices that some great, especially new enterprise product teams are actually taking seriously because again, the users are people and sometimes they need to find a fun way before they can find an important way of using the new tech. So another adoption or observation I'm thinking about a lot these days is just how much the future of enterprise tools is this multiplayer default. And if you think about the types of, I mean, a few examples, and I'm using many examples I'm an investor in, but just because I know these companies well, I mean, graphi, you know, they're building this data visualization product and the first thing you do is you define who else is on your team and who should have access to the graphs you're making. And then suddenly, before you know it, other people who are normally not involved with the analytics or data analysis part of the organization are chiming in and building their own graphs and making comments and asking questions. And we've seen this in other products like Airtable Globality for procurement, one of our own at Adobe XD where it comes to design systems and prototype review and that sort of thing. These are modern products where you're actually, they're actually in some cases, collaborative by default. You literally set up Your you know your team before you even start to enter and use the enter data and use the product. But they are built as multiplayer systems. And that means that stakeholders are super important. It means that there are oftentimes web, you know, web apps. And so I think there's a lot of questions that this starts to change the answer for as you're designing enterprise experiences. I mean, who are you designing for? I think that the age old way was really focusing on a specific function and nailing it and building that perfect application for that function at the expense of accommodating and being inclusive of a far larger spectrum of potential users. And now you're not only designing for that siloed function, you're also saying, okay, what are the all, what are all the possible stakeholders that are going to interact with this product? What are the specific needs of each of those stakeholders? Developers versus people in the C suite versus customer service folks. If all these people jump into this product, do they all see the same thing by default? Do they see different things by default? What's the permissioning? Does the permissioning have to be defined up front or later on? Who are the admins who can manage permissioning and how do you expand that group so that it's more flexible as a system? These are all the types of questions that this multiplayer mode for enterprise products raises. What are you selling? Typically you're selling for these no needs of that siloed function that you're trying to serve with your product. And now it's really about all the other needs that the organization might have as they become stakeholders of this product. And what types of outputs do they want? If an executive logs into a system and sees the graphs, should they see fewer levers to get confused by and should they have an export functionality for PowerPoint? Because that's the need of that specific stakeholder of this multiplayer product. And also how are you charging? I was having a conversation yesterday with a pretty big investor in the enterprise space and he was saying how people, in some cases to the benefit of these enterprise companies are not doing the math on the cost of all of these viral spread users, the stakeholders that are coming in and suddenly starting to find a use case for the product that maybe the company that signed up for this enterprise wide license didn't anticipate. Are you only charging for the folks in the siloed function and then everyone else is a free stakeholder user? Or are you charging different tiers? Or is everyone just a paid customer as soon as they come in and start to actually enter or extract some value into the system. It's actually changing the entire business model of the rollouts of these products. And so I think that when you're building any enterprise product and you know, how do you make it? Multiplayer from the onset is going to be a theme in the product and design organizations of pretty much every enterprise product you can think of. Because, you know, we're all stakeholders to some degree. All right, so that's like kind of 2 thoughts on the simplicity and the, you know, the, the edge of design or the disruption, if you will, of the interface itself and the role of collaboration. First, approaches to building enterprise products. And then the third area now I want to do a bit of a fun, somewhat polarizing deep dive with all of you in is around the tendencies of people with a bit of a lens on enterprise people or people in their enterprise mode, I should say, because all of us employees and consumers and everyone in between, we are all lazy, vain and selfish in the first mile of our experience using a new product and service. That's not to say that you can't build a rapport with your customer, help them unearth a lot of the longer term value of your product, and then have them commit to investing and making it theirs. Of course, however, in this first mile of our experience using any product, and let me explain to you, let me explain to you why. So in the first 15 seconds we are all lazy, right? We don't have time to learn something, to go to read something. We don't want to be trained. And so we've all seen and went through these bad onboardings where there's just too many examples, instructional videos or mandatory training services that are thrown at new adopters of technology and enterprise. No one really wants to participate in this stuff when people click through it. And everyone has a little more confidence in themselves than they should in terms of how intuitive something will be to them. Everyone thinks, I'll figure this out and they get it and they realize that they didn't or they even worse think that they did and they never use the product properly. And of course more than one line of copy typically doesn't get read. And there's all sorts of heat maps of eye movements on pages and stuff to back some of that up. And so what do we learn from this? Well, first of all, it's always better to show someone something rather than explain something. So the use of tool tips and that sort of thing within product onboardings is super crucial. Helping people get through that first mile. But even better then showing someone how to do something is doing it for them. And the most successful products that I see really get this right. They land people in templates. They have smart selection as opposed to manual entry. They have really, really incredible presumptuous defaults, or they'll put in sort of chat UIs as a way of bringing someone through and experienced rather than having them have to start making choices in isolation and getting kind of anxious about that process. I mean, one thing I would say is that my favorite saying in product design is from my friend Dave Marin, and he likes to say that the devil is in the default. And that couldn't be more true. Whatever we design determine is the default experience for our customers ends up being the thing that they basically stay with forever. And you know, and we just want to eliminate options at all costs, of course. So there's a lot of work and time that needs to be spent on this first mile in order to make sure that we capitalize and accommodate people's laziness. And by the way, it is the ultimate irony that the last mile of a team's experience building the product is spent considering the first mile of a team's experience using the product or a customer's experience using the product. I mean, it's kind of amazing that the only part of all of our products that every customer or every prospective customer will experience is the top of the funnel is that first mile. And of course from there it's just severe drop off. And yet not until the end of our cycle you, you know, building a product, in some cases over years do we say, well, what should the default experience be and who's going to do the onboarding and the tour and what should the copy be and what should the splash page be and what should that first day and third day and seven day email be and what should we do when we start to see patterns of a customer exiting the first mile experience and how do we save them and what's the graceful failure when we know that someone is struggling? Those questions, if they're asked, they're asked at the end. And I would argue that we should flip the model. Let's make sure that we get everyone at the top of the funnel through a very successful first mile experience and then let's really make sure that they find their quick path to unique value from the product. And let's not build something wonderful and lose everyone before they even get through the, the metaphorical door. So we're not only lazy in the first 15 seconds, we are also vain. We are vain in the sense that whatever we're enduring or going through this better make us look good and quickly. And so here I bring up the topic of ego analytics. And this is one of my favorite debates to have with the builders of products. Because everyone wants to think that their customers are above this. And we are, except not in the first mile, not in the first 15 seconds or the first number of use cases. We all want to know that we are loved and looking good. There's a lot of examples of this over the course of my career as an investor working with teams and companies. The previous one was Periscope, which sake of time I'll move on from. I mean, one other classic example we probably all see in our lives is when you open up Instagram and of course instantly you see, you know, how many likes you have or hearts and how many new follows. Which leads me to an observation that when you look at the graphs of a lot of these companies with any form of vanity feedback or ego analytics, what you find is that people are more active in the product after they have posted something because they want to see what other people thought of the thing that they did. And if you look at a engagement graph or a product like Instagram, you'll oftentimes see that there's this kind of level engagement and then you post a new photo to your stream and then suddenly you're going in all the time to see what people are saying about the thing that you posted and then it kind of levels off again. And so the dirty little secret in social consumer products is that they are as much about seeing who saw your content as they are about sharing and seeing others content. And so how do we kind of bring this back to the enterprise and making great, sticky, useful and beloved products in the enterprise? Well, one of the things we should do is we need to merchandise our customers progress and success to our customer. Like they need to know that they are making progress. I did some research my second year at business school with a woman named Theresa Amabile and she is sort of like a world renowned researcher on creativity and business at Harvard. And she did this big study of people teaching diaries in the enterprise and of big companies and she was studying creativity. And but her big kind of takeaway from her research was that progress begets progress. When people feel like they're making progress, they're likely to make more progress. And so it is a bit of a chicken and egg thing which then leads to the role of a leader in a team to merchandise the progress that his or her people are making to keep them motivated and going. And of course there's a whole other genre of discussion around what that means for startups and building teams. But now we're talking about what it means for product utilization. If you can make sure that your customers feel like they're making progress, like they're successful, they're more likely to engage further in your product. They're also more likely to feel good about themselves and therefore like your products. Because if the product makes them feel good about themselves, that is a good thing. And so we need to also, in the enterprise, design products that help people get not only feel good about themselves, but get credit for their work. This is one of my favorite examples. One team that I work with realized that if they could allow people in this enterprise dashboard of this pretty traditional enterprise data rich product for reporting, if they could allow their customers and enterprise the users to print editable reports or export as Excel sheets, that was just like people loved getting these editable reports so they could put their name on the top and basically essentially have this output for their bosses or to send around. And no one really, if you were just a receiver of this, no one knew that the tool that they use exported 80, 90% of this. And then they just kind of put their own finishing personalization touches on it and then sent it around as their report to their team. They looked so great, they looked great to their peers, they look great to their bosses. And this little feature becomes really important. Now traditionally in an enterprise product team, it's like, let's just have it export as a PDF and people can just get the same data standardized. And why spend time making it designed really well, making it editable, you know, all this stuff. But that stuff matters because you're feeding into the vanity, you know, of the customer, especially in their early, you know, experience using your product and doing so drives utilization. Finally, in this, you know, first 15 seconds, we're also a bit selfish, right? We need to benefit very quickly from this without spending any time. Yes, this might be great for my team or for my organization or whatever else, but this does also kind of need to feed me really quickly because I've got a lot going on and I have a lot of demands on me and family and everything else. And gosh, they're going to make me use this new tool. It better serve me fast. And we are all skeptical of a long term promise of a product. And so it's not enough to get us through that first mile. We need something else to get us value. Now there's A few examples I've seen over my career. 1 Pinterest I remember Ben Silberman in the very early days this was really about keeping your collection. And yes, the promise of a community and discovering other content was always part of the plan for him. But he was actually laser focused on the collector at first and making sure that they had the very best way to manage their own collection in that selfish way of like, I don't think I want to discover other people's stuff right now, but I want to better. At the time it was delicious and a few other apps online that people use to manage collections of their own stuff. And so he was really laser focused at first on this immediate utility for collectors and not necessarily this value proposition at the onset. You know, come and discover your interests. Wow, that's really cool. But it doesn't, it doesn't really serve my immediate need right now. We talked about the importance of novelty preceding utility, but that also plays in here amusing people as a way of teaching and engaging them over time. I love some of these other value propositions get paid faster for Square I remember hearing that they tested a lot of early value propositions around managing your business and you know, all these other things that you'd think would be top of mind in terms of long term needs for a small business. But in fact the thing that they really cared about was just getting paid faster. And that was a good example I think in that first mile insights of what feeds the selfishness of the customer, even though what's really best for them over time is something even more than getting paid faster. And this really gives a sense of the empathy that Square had with its customers problems in their early days Stripes famous allure to developers to get payments with two lines of code at a time when developers had to deal with all these different intermediaries of the payments world and just deeply complicated integrations to get simple payments. And then every time a new region came online or a new currency, it was just absolute madness. And so this notion of two lines of code really served the serve the developers selfishness and desires first and foremost. So I think that the point of this, which is somewhat controversial, especially to all my enterprise leaders and friends listening to this talk, is that marketing and copy should be born with or in the product team because it's part of the product experience. A lot of new consumer and enterprise companies figure this out in their startup phase by necessity it's all the same people and so everything seems perfectly integrated and thoughtful and the marketing and copy can change on a dime to accommodate some of these insights we're discussing here. But as we all know, in larger companies and with organizations set up for scale, it's hard to get marketing and copy in line with some of these product priorities and also to be able to iterate them to make sure that, you know, you're, you're appealing to the selfishness, you know, of your customer in real time. And it changes, of course over time. So that's something for all of us to think about as we're, as we're challenging the organizational model of some of these modern, modern enterprise SaaS experiences. So I guess the three major things I was hoping to impart and in this early morning talk here is one is empowering. Design to me is like this underestimated secret sauce. And it's just amazing how little design has a seat at the table still in the world of enterprise big companies, design is treated like a internal or external agency where you just throw stuff over the wall and get it back and then whatever ships is usually at least 30 to 60 degrees off of what the designer intended. Designers typically are not the ones presenting their own the products that they're influencing. And in this world where decisions are made at the surface that interfaces are disrupting all the other services underneath, how could designers not be among the most, if not the most important, you know, pieces of the puzzle of being competitive in the enterprise, you know, is amazing to me. So I encourage all of you to think about how that applies to your organization. And we have to stop design just for the functional user, but really take the team and the stakeholder into account. This multiplayer mode has huge implications for a lot of the things we discussed, like how you charge and who you're building for and how the product works and what the defaults are, et cetera. And I just think that this siloed function specific model for enterprise is kind of yesterday and not tomorrow. And we need to get ahead of that, all of us. And then third is also making sure that we understand the human tendencies of our ultimate users. And that lazy, vain and selfish set of insights can help US achieve that top 1% of enterprise adoption. It's true more than ever before now that a product that people love to use has a very great competitive advantage. Which sounds silly and obvious to say, except as we all know, it hasn't always been the case. People have typically suffered through whatever they were told to use. And yeah, things have changed based on these aggregators, these interfaces that are taking these old clunky tools and putting new surfaces on them and then competing with them or the next generation of these enterprise products that are rising and playing that product life cycle of users flocking to a simple product. All right, so with that, we are now at the point where I think we have about 10 or so minutes for any Q and A discussion. And I'm happy to think I'll stop sharing the slides just so I can see the see anything in the chat and take it from there. So let me take a look here and feel free anyone, you know to add anything into the chat that is of interest to you. So would I be able to share the long list of insights after the talk? Yes, I think these slides will be made available. I think that's what. Yep, we already answered that. Sorry. Okay, look at further down. If you click the Q and A, you'll be able to. Am I in the wrong one? Oh, Q and A. Sorry, I was in the comments. Right. We use blue jeans at work, so it's a different model. Okay, so. Hey, Jason, you're excited. Awesome. Thank you again for having me. At what point does the inertia of being on a platform like AWS that may have subpar experience for some features supersede individual point solutions that may provide a better experience? That's an interesting question. Well, first of all, competition in these underlying platforms certainly helps because once users have choices, then some of these finer points matter more to teams. And I think it's interesting. Let's see where that question goes. I think that, I mean, I find it fascinating, the bundling and unbundling of these products. And part of it is driven by the desire to have these point solutions that are highly specialized, easier to use, and care about the little things that make a big difference. And then you start to atomize your workflow with all these little things all over the place until someone comes along and says, hey, we're bundling it all. And wouldn't that be amazing if all of this was vertically integrated in this same product? And then teams get excited about that and then they adopt it, and then before you know it, the whole thing happens all over again. Which is actually one of the reasons why I don't love investing in productivity tools. Because I actually feel like, generally speaking, with some exceptions, productivity tools suffer not only the, you know, everyone says switching, switching costs. And, you know, how that keeps customers entrenched in a product really long. Well, actually, productivity tools have another phenomenon called switching benefits, and that is like the spring cleaning, where a project manager or program manager or a product manager comes in and says, hey, we're going to clear the decks, we're going to handle all this organizational debt of stuff that is accumulated and we're going to just, let's just use a new project management tool. Let's just start from scratch. I heard this one was great. And everyone's like, great, because when you have novelty, it precedes utility. And so when some people, when people get a new productivity tool to use a new way to, you know, manage their Gantt charts or their water flow or whatever waterfall work or you know, any sort of system for team productivity, they suddenly, you know, for whatever reason, you know, gravitate towards it and it's a way of re engaging people. And that's great maybe for teams to switch it up. But you know, for productivity teams, for productivity tools is not really a winner, winner take all oftentimes because of that phenomenon. So how do you balance expectation management between the results that give value in 15 seconds in the three to six months it will take to transform the team? It's a great question because it's an experience that you're building for your customer and you have to, yes, they do have to reach a specific set of KPIs in three to six months and with your product to make it feel like it's worthwhile. And at the same time, we can't ignore that kind of immediate sense of gratification that breeds utilization. This is the symphony that we are designing as product builders in the enterprise is we have to do both. And I think on the longer term side, the answer is more of the traditional shoulder to shoulder customer empathy, seeing what they're using and what they're not using and optimizing the product over time. The challenge is that companies launch their products if they're top 1% product teams. They think about that first mile experience and get it right. People come into the product and then they assume that since they nailed that onboarding, that first mile experience, that forevermore they can focus on the long term value that customers get out of the product. And that's a mistake because every cohort of new customers is different. I actually will take a second to talk about this because I think that we kind of assume that once you nail the onboarding, it works. The problem is that as we all know, especially with enterprise products, there's a certain set of customers that are willing to be forgiving and tolerant of a new enterprise product out of the gate that may not be truly enterprise ready, that may have some integrations missing still that doesn't have A third party ecosystem, yet whatever else. And those forgiving customers are a little more tolerant of that first mile experience and what it's missing than say, the late adopters that are using your product because they were told to. And they are the holdouts in an organization that are finally, finally adopting this new technology. The first mile experience for those customers is a different one. And there's some great experience. I think they're great examples in the world of companies that nail the first mile experience for a cohort of customers and then miss the next cohort. And I mean, in a dramatic example, maybe Twitter is one of those where you could argue for whatever 150 million users that were willing to actually painfully make their timeline so that they got a lot of value out of that product. Twitter was great. But then after that set of customers, potential customers in the market, you got people who just came for news and they had no interest in following individual accounts and curating a timeline over time that would give them value in the product. And as a result, I think Twitter suffered for a while and to some degree still with that, you know, that kind of new cohort or next, you know, new generation, not generation, but entirely new, psychographic rather of customers. And so it's something to think about and that's why you have to consistently allocate time and capital, that first mile experience. So Jason's asking, what have you learned driving organizational change at Adobe? And this has been a lot of fun. I mean, I, you know, I've been deeply passionate about building for the creative world for, you know, for most of my career. And Adobe has the combination of challenges around thinking about how to make our products more accessible to more people. Just increasing the number of the percentage of people that are able to successfully set up and use our products and figure them out. A very small change. There is obviously a large impact in a subscription business like ours. And so I was really excited about the opportunity on the retention engagement area in the near term. And I was also super excited about, over time, medium term bringing our products to the cloud because they were always kind of local downloads and now you're getting tons of cloud value out of these products. You're saving Photoshop documents in the cloud, you're going to have the ability to co edit and have fonts just pipe in wherever you load up a file, et cetera. And then even over the longer term, the 3D and immersive medium and pushing, helping push creatives from the mediums that they know into the mediums that they need to be prepared to create in. And so there's been a lot of organizational change at Adobe to make this possible. And I think that I always, I think it was the historian Jonathan Sarno that said discontinuity breeds continuity. And I do believe when you're trying to keep an organization nimble and trying to rethink the problem in new ways, you have to keep moving people around. You have to have a culture of agility where people actually are tolerant and welcome of that, as opposed to everyone freaking out about any little organizational change or movement. So I would say first and foremost trying to open the team's minds to the benefits of this and then working with just some of the industry experts across mediums like video and design and digital imaging to chart the course for the future. It's been a lot of fun and also helping empower design further in the organization with a lot of the principles we talked about today are things that I also talk about with my teams. So suggestions for startups building developer tools. Well, there's obviously this low code, no code movement and expanding what a developer even means I think is a really interesting trend right now, because why should so many stakeholders not be able to even touch or understand the development process of a product? The multiplayer principle we talked about today hugely applies to startups building developer tools today, I believe. Also, I think the approach to an ecosystem, I mean, there's just so many different developer tools out there that are deeply specialized these days and making sure that from the onset you're not building a closed system, but obviously embracing that. Those are just a few thoughts. A question around from Kyle. How do you suggest designers advocate for a seat at the table? It's funny, I mean this notion, one of my favorite sayings these days is that a prototype is worth a thousand meetings. And we've all been in meetings, especially by the way, in building an enterprise product where people go around and talk about a market opportunity and the types of features something needs and how to make sure that you light up something that leverages, that connects these two different audiences with the same workflow or whatever else. You know, every enterprise is trying to crack something like this and it's just amazing how long that conversation will go and how many times it will happen until people actually take the time to just review a prototype and see rather than discuss. To me, a really thoughtful prototype is like a hot knife cutting through the butter of bureaucracy when it comes to understanding how an enterprise product will add value to customers, but also become a business. And the only way to suggest or Advocate for designers to have a seat at the table is to show what they're capable of. And so I think one of my hacks, if you will, for this is I like to identify some great production designers who really can just get in the weeds with me and cracking a kind of North Pole prototype of where we believe an experience should land, just generally speaking. And then when you put that in a conversation amongst executives, it rapidly accelerates. It's like throwing a flag distant and then going to where the terrain is that you should actually be exploring. And it gives people something to react to. It's a strawman, if you will. And once you do that, if you have the designer who did this present, then suddenly everyone in the room awakens to the role of a designer in cracking a solution. And nothing's better than that. And I think, you know, all of you should try to make that happen more. So if you can and hire great designers and pay them really well, that also helps. What percentage of your dev work should be focused on? Let's see, I just lost that one. On interfacing and customer experience. Yeah, or interface and customer experience. Well, it's a controversial response, right. In the traditional enterprise SaaS world that sort of sold products that weren't even fully functional yet, and it could get away with inferior interfaces and shoddy customer experience. There was a business case for shipping quickly, selling ahead and moving in that way. I do in the world of multiplayer, you know, in the world of these other interfaces disintermediating the services underneath, you know, I think the calculus is changing. So this is maybe a matter, a matter of habit or, you know, I don't know, everyone's different on this one, but I like to over index interface shocker. And I do believe that you can distinguish yourself from the customer experience. You have a much larger set of potential buyers and advocates in the organization. Even if you're selling to someone in procurement or the CIO or whatever else, if you have the people that are using this product day in and day out as fierce advocates for what you're offering, as we all know, that's a pretty healthy sales booster right there. And then. While every SaaS tool needs a dashboard, what design approaches can help us stand out? Well, I really like taking the consumer lens. I like to think about the types of things people like to do as opposed to what the enterprise needs from our product. People like to be welcomed in the morning. They like to be able to personalize their dashboard. They like it to be really easy to figure out the UI Elements matter a lot of these queues. Again, we have an increasingly less forgiving user base and we also have increased confidence that people vocalizing their displeasure. And we do have to take that into account. So when I was talking about top 1% enterprise adoption, I was just actually referring to being in the top cohort of enterprise products out there as it relates to successful adoption of their product and usage. So if many enterprise products are spread and people go in once and they either don't want to come in again or they refuse to go in again, they just stop using it or they just delegate it down, how do you get to a place where people are like, oh wow, this is a place I want to come back to. There are more and more enterprise teams that I meet with are talking about how they want to get C suite logging in as almost like a metric. They're saying to themselves, yes, we're selling to this function or whatever, but we want to build something that the C suite would also access or be able to get if they get a report via email with a link that they can go in and use this. Which of course super, super helpful when we are trying to get budget for the re up for, you know, for our own products. So let's see. I think we have another. I think we're in our last minute here. Maybe I'll take one more question here. So let's see. Let's talk about bottoms up adoption. I like that one. How do you take into account the buying team? Do you just build executive dashboarding or something else? I guess we talked about this a little bit, but I actually would encourage these new multiplayer products out there to visualize what different stakeholders of the product see and to over index on showing rather than telling, even on the splash pages of their company websites. How do you actually show what it feels like to use your products? How do you. I know a number. I remember Airtable. I mean, airtable has thrived off of the open marketplace of templates and people just jumping in and feeling it. And at the top of the funnel at airtable, I remember Howie telling me that most people just kind of jump into a template that serves their purpose, like project management or ad optimization, tracking or whatever the template's made for. They land there and they visualize how great this can be for them. And then they advocate to their procurement or whoever is making the purchase decision that this is the option that they want to proceed with. Okay, anyways, so many great questions here, but I'm going to leave all of you for the break before the next session. Thank you, Jason, and the whole Sasser team for just doing everything you do to start these conversations and for having me hope everyone else is safe and healthy. And thanks again for tuning in. I'm Scott at Scott Belsky on Twitter if you want to keep in touch. Thanks again.