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

because we're all people, would want to kind of 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 kind of 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 like who reports to who and what organization everyone is in. And then before you know it, maybe you actually start to, uh, 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, you know, threatening the providers of the services underneath. And, and that's, you know, just a reminder that the choices that we ultimately make in our day-to-day lives, both as consumers as well as, as, as workers within the enterprise, are made at the, 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, you know, in the surface business. And, 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, 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, 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, the, 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, Hey, like, why do I have to use this clunky thing when, you know, so-and-so over there is, you know, using their corporate credit card and has a far superior, you know, surface to interact with on a daily basis? And I think it's a really exciting trend because this is, you know, one of the themes of this presentation will be the power of design and empowering design to have a seat at the table, you know, 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, this observation that a lot of industries are playing this kind of slap-a-hand game where whatever interface at the top, you know, 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, you know, their, their happiness in terms of whether they want to adopt and start using the product or not. And this top-down mandated sell, you know, as we all know, um, that's that, that, that motion of sales is becoming, you know, a little threatened by some of these, you know, more bottoms-up approaches. And I 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 frameworks and services. It's really starting to be the design that is further differentiating some of these products out there. I'll put it that way. And so 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, it was kind of like a trading floor, and they put in these brand new, very expensive 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, nobody was using this technology, this expensive installation. And then, you know, 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 1." People were like, "Con 1, what does that even mean?" Of course, people realize, oh, there's this little Con— Conference 1 button, like I'm going to 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 mean, 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 coffee room. Hey, I'm going out for coffee, anyone want to come with me? And then of course, you know, fast forward a few weeks and suddenly the team has, um, has moved on and adopted this new enterprise technology. And so I think there's a message here around novelty preceding utility, uh, increasingly in enterprise product adoption. And it's weird because when we're building the stacks for products, you know, especially an enterprise SaaS product, the last thing you're doing is thinking about 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 flywheel 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, they're building this data visualization product. And, you know, the first thing you do is you define who else is on your team, 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, you know, 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 they're 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, you know, 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 the— 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 positioning— uh, 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, um, that this multiplayer mode for enterprise products raises. Um, what are you selling? I mean, typically you're selling for these known 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, um, and, and, you know, what types of outputs do they want? If an executive logs into a system and sees the graphs, should they see fewer levers to, uh, to get confused by? And should they have an export functionality for PowerPoint? You know, 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. And so are you, are you only charging for the folks in the siloed function and then everyone else is sort of 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? And so 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 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 we're all stakeholders to some degree. All right, so that's like kind of two thoughts on the simplicity and 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, you know, 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. And, uh, and 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 the first 15 seconds, we are all lazy, right? We don't have time to, uh, 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, um, instructional videos, um, or mandatory training services that are, that are, you know, thrown at new adopters of technology 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, you know, everyone thinks, "Oh, I'll figure this out," and they get it and they realize that they didn't, or they, you know, 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, you know, there's all sorts of heat maps of eye, you know, eye movements on pages and stuff to back some of that up. And so what did we learn from this? Well, first of all, it's always better to show someone something rather than explain something. And so the use of tooltips 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, 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. And they'll put in sort of chat UIs as a way of bringing someone through an experience rather than having them, you know, have to start making choices in isolation and getting, 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 Morin, and he likes to say that the devil is in the default, and that couldn't be more true. Whatever, whatever we design or determine is the default experience, you know, for our customers ends up being the thing that they basically stay with forever. And, uh, and, you know, and we just want to eliminate options at all costs, of course. So, so there's a lot of work and time that needs to be spent on, on this first mile in order to make sure that we, we capitalize and accommodate people's laziness. Um, 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 know, building a product, in some cases over years, do we say, well, what should the default experience be? Oh, 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, you know, exiting the first-mile experience? And how do we save them? And what's the, 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. You know, let's make sure that we get everyone at the top of the funnel through a very successful first-mile experience. And then, you know, then let's really make sure that they find their quick path to unique value from the product. And let's not, you know, build something wonderful and lose everyone, you know, 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, uh, this better make us look good and quickly. Um, and so here I bring up the topic of ego analytics, and this is one of my favorite, um, uh, kind of debates to have with the builders of products. Because everyone wants to think that their customers are above this. But, and we are, except not in the first mile, not in the 15, not in the first 15 seconds or the first, you know, number of use cases. We all want to know that we are, you know, loved and looking good. And, you know, I, there's a lot of examples of this over the course of my career as an investor working with teams and companies. I mean, the previous one was Periscope, which In the 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 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 an engagement graph for a product like Instagram, you'll oftentimes see that there's this kind of level, you know, 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, uh, 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, how do we kind of bring this back to the enterprise and, um, and making great, sticky, useful, and beloved project products in the enterprise? Well, one of the things we should do is we need to merchandise our customer's progress and success to our customer. Like, they need to know that they are making progress. I did, um, 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 keeping diaries in the enterprise and of big companies, and she was studying creativity. But her big kind of takeaway from, 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 the leader in a team to merchandise the progress that his or her people are making to keep them motivated and going. And, uh, and of course there's a whole other genre of discussion around what that means for startups and team 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, and therefore like your products, because if the product makes them feel good about themselves, that's a— that is a good thing. And so we need to also, in the enterprise, design products that help people get not only, you know, feel good about themselves, but get credit for their work. And this is one of my favorite examples. One team that I work with realized that if they could allow people in their— in this enterprise dashboard of this, you know, pretty traditional enterprise, you know, data-rich product for reporting, if they could allow their customers in the enterprise, the users, to print editable reports or export as Excel sheets, um, that, that was just like, people loved, you know, 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, you know, no one really, if you were just a receiver of this, no one knew that the, the tool that they use exported, you know, 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, ah, you know, we can just— 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, uh, you know, of the customer, especially in their early, you know, uh, experience using your product. And, um, and doing so drives utilization. Finally, uh, 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, you know, feed me really quickly because I've got a lot going on and, you know, 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. Like, it better serve me, better serve me fast. And we are all skeptical, right, 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. And I mean, there's a few examples I've seen over my career. One, 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 kind of 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, you know, 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 really like serve my immediate need right now. We talked about the importance of novelty preceding utility, but that is, you know, that also plays in here, you know, amusing people as a way of, you know, teaching and engaging them over time. I love some of these other value propositions. You know, get paid faster for Square. You know, 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, you know, 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, you know, gives a sense of, you know, the empathy that Square had with its customers' problems in the early days. Stripe's famous allure to developers to get payments with 2 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 2 lines of code really serve the developer's 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. Like, it's all the same people, and so everything seems perfectly integrated and thoughtful, and the marketing copy can, you know, 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, you know, in line with some of these product priorities, and also to be able to iterate them to make sure that, you know, 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 challenging the organizational model of some of these modern enterprise SaaS experiences. So I guess the three major things I was hoping to impart 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 an internal or external agency where you just throw stuff over the wall and get it back, and then whatever ships is usually, you know, at least 30 to 60 degrees off of what the designer intended. Designers typically are not the ones presenting their own, uh, the products that they're, you know, influencing. And, and, um, and, you know, at this— in this world where decisions are made at the surface, that interfaces are disrupting all the other services underneath, I mean, how could designers not be among the most, if not the most important pieces of the puzzle of being competitive in the enterprise is amazing to me. So I encourage all of you to think about how that applies to your organization. And we have to stop designing 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. Oops. 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, a very, uh, you know, great competitive advantage, which sounds silly and obvious to say, except as we all know, it hasn't always been the case. I mean, people have typically suffered through whatever they were told to use, and, um, 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, you know, the next generation of these enterprise products that are rising and playing that product lifecycle 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&A discussion, and I'm happy to— I 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, um, would I be able to share the long list of insights, um, after the talk? Yes, I think these slides will be made available. I think that's what— yep, we already answered that. Sorry. Okay. Uh, look at further down. Um, if you click the Q&A, you'll be able to find the wrong one. Oh, Q&A, sorry, I was in the comments. All right, we use BlueJeans at work, so it's a different model. Okay, so hey Jason, you're excited, awesome. Um, thank you again for having me. Uh, at what point does the inertia 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 did that question go? Oh, yes. I think that— I mean, I find it fascinating, the bundling and unbundling of these, you know, products. And part of it is driven by the desire to have these point solutions that are highly specialized, easier to use, and, you know, take, you know, 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 the 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— everyone says switching costs and 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, you know, 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 get a new productivity tool to use, a new way to, you know, manage their Gantt charts or their Waterflow 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, it's 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 and the 3 to 6 months, you know, it will take to transform the team? It's a great question because, because it's an experience, right, that you're building for your customer. And, and you have to— they, yes, they do have to get, reach a specific set of KPIs in 3 to 6 months. you know, with your product to make it feel like it's worthwhile. Um, and at the same time, you know, we can't ignore that kind of immediate sense of gratification that breeds utilization. You know, this is the, this is the symphony that we are, uh, designing as product builders in the enterprise is, is we have to do both. And, um, you know, 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, um, and, uh, that's a mistake because every cohort of new customers is different. I, I actually will take a second to talk about this because I think that, you know, we kind of assume that, um, that once you nail the onboarding, it works. The problem is, 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, you know, 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 nailed the first-mile experience for a cohort of customers and then missed 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, you know, 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, you know, with that that kind of new cohort or next new generation— not generation, but entirely new demographic, psychographic rather, of customers. And so it's something to think about, and that's why you have to consistently allocate time and capital to 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'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. You know, just increasing the number of, you know, of the percentage of people that are able to successfully set up and use our products and figure them out, you know, 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 know, 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, and, you know, have fonts just pipe in wherever you, you know, load up a file, etc. And then even over the longer term, the 3D and immersive, you know, medium and pushing, you know, helping push creatives, you know, 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, you know, I always— I think it was the historian Jonathan Sarna that said, you know, discontinuity breeds continuity. And I do believe, you know, when you're, 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, to, 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. 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 1,000 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, all, 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. Um, 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 what, you know, how an enterprise product will, will, will add value to customers, but also become a business. And the only way to suggest design or advocate for designers to have a seat at the table is to show what they're capable of. And so, you know, I think one of my, you know, 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 straw man, if you will. And once you do that, if you have the designer who did this present, then suddenly the, you know, everyone in the room awakens, you know, 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, oh, 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, you know, functional yet, and it could get away with inferior interfaces and shoddy customer experience. You know, there, there was a, there was a business case for shipping quickly, you know, selling ahead and moving in that way. I do, in the world of multiplayer, in the world of these other interfaces disintermediating the services underneath, I think the calculus is changing. So this is maybe a matter of habit, or I don't know, everyone's different on this one, but I like to over-index on interface. Shocker. And I do believe that you can distinguish yourself on the customer experience. You have a much larger set of potential buyers and advocates in your organization. And, and 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. Let's see. And then, while every SaaS tool needs a dashboard, what design approaches can help us stand out? Well, you know, I, I really like taking the consumer lens. You know, I like to think about the types of things people, you know, like to do as opposed to what the enterprise needs from our product. So people like to be welcomed in the morning. You know, they like to be able to personalize their dashboard, and they like it to be really easy to figure out. The, the, the UI elements matter. A lot of these, you know, a lot of these cues— again, we're— we have a increasingly less forgiving user base, and we also, you know, have increased confidence of 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 use— and usage. So, you know, if, if, 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. You know, how do you get to a place where people are like, oh wow, you know, this is a place I want to come back to? Uh, there are, you know, more and more, uh, enterprise teams that I meet with, um, are talking about how they want to get C-suite, you know, logging in. 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, uh, uh, for the re-up for, um, you know, for, for our own products. So let's see. Um, 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, you know, showing rather than telling, even on the splash pages, you know, of their, of their, you know, company websites. And how do you actually show what it feels like to, um, to use your product? How do you— I know a number— I remember Airtable. I mean, they're, they're, you know, Airtable has thrived off of the you know, open, uh, open marketplace of templates and people just jumping in and feeling it. And, you know, at the top of the funnel of 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, you know, to their to their procurement or, you know, 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 M. Lemkin and the whole SASR team for just doing everything you do to start these conversations and for having me. Hope everyone else is safe. Healthy. And thanks again for tuning in. I'm Scott, @ScottBelsky on Twitter, if you want to keep in touch. Thanks again.