Salesforce, Dropbox and Slack: Building and Monetizing A Partner Ecosystem

Welcome, everybody, to your final panel before your drinks begin for the evening, or hopefully some of you have already started that I know our panelists have. I'm really excited and privileged to be here today with April, Ilya and Neeracha from three of the pioneer companies in the industry to talk about platforms. And as we were coming up here, Jason's like, it's a bar theme, it's a moderating. And I was like, I really don't understand what's going on. But I thought about it and I said, over the past nine years at Appirio, I've bought people over 100,000 drinks and consumed zero in that period of time. So I think I have the best ratio in the industry. But it also for this panel means I'm very good at using alcohol to extract information. So I'm hoping to do that today with you guys. In fact, I think in addition to your drinks, there'll be some shots coming out and I'm curious to see if anybody's brave enough to actually undertake. So we're going to get started. I gave them one question that I told them I was going to ask and the rest of it we're going to just wing it. But I started off by asking, you guys are in three of the leading platforms in the industry. Amazing success. And I said, what's the name, movie or person that represents your platform and what you think about the world? So I'd love to hear what you came up with after that. Anybody want to start?

Sure, I'll get started. My name is Neeracha. Teichakunavud is my last name. It is the longest name on the poster today, I want you to know. And I'm from Salesforce and I agonized over this question, Narinda, like a ridiculous amount of time. I crowd sourced it, talked to my team, and in terms of what rest represents our platform, I came up with Jon Stewart, which is very appropriate for the set. I didn't realize this was going to be the set today. And the reason I say Jon Stewart is fake news. Very underrated in the beginning. And then as he developed an audience, it turns out that he was voted the most trusted newsman in a Time magazine poll. And the way it links to the Salesforce platform is, you know, the App Exchange has been. We actually celebrated our 10 year birthday last month and it did start out as a small offering, just starting. What is an App Exchange anyway? No concept of the App Store existed in a B2B world and it was much more than just a directory or a listing service. It really is a an actual storefront for B2B apps. And then today it is one of the most trusted platforms out there. So, Jon Stewart, for me, that's great.

So I want to ask, are there any Star wars fans in the audience? I want to apologize to you because I know Star wars is really serious business and I don't want to bastardize it in any way, but I would say that I chose Star wars because it's a really interesting storyline in that you have this great team of humans that are working together, but actually the droids are some of the best personalities that are part of the team that really help them get things done. And so, as you mentioned, I'm April Underwood. I run a product over at Slack, and a lot of what we're doing at Slack is creating a communication platform that allows teams to work together better. But the platform we've built allows apps to join that conversation and to bring personality to solving work tasks. And so I'm going to go with BB8 and R2 and that gang as a pretty good representation of what we hope some of the great apps on top of Slack might look like over the coming years.

Cool. So I'm Ilya Fuschman. I'm currently a general partner at Index Ventures, but I spent the last four years at Dropbox where I did a bunch of things, including working on the platform. And for us, the vision around platform was always to build the dashboard or that surface that Tom Cruise has in Minority Report. The idea was to get all of your most important data in front of your fingertips, have one central source of truth, and then have applications that live on top of that, that provide utility on top of your data. So I'm going to go with the Tom Cruise Minority Report dashboard.

Great. Well, I think one of the things is platforms, even amongst you guys, but certainly broader mean a lot of things, right? Platforms can be something you build on top of. Platforms can be something that extend your product and the functionality that's there. And then sometimes platform is the facilitator and it's only about the content on top of it, like YouTube or iTunes. So thinking about that, I want to start neeracha with you and the what and the why, Like Salesforce is both a platform you can build upon, but then also you guys have a platform that extends your functionality. Do you think of those things similarly differently? How do you approach the strategy of why your platform is what it is and how you're trying to move forward with it?

And that's A great question. And we get asked that by customers all the time. And the way I speak to customers about our platform, we call it the customer success platform is. It is a platform. And on top of that you can build your own apps, all the development tools are there. You can use our apps, CRM service, et cetera, or you can buy an app from the App Exchange from one of our many partners. So it is kind of a mix and match for the Salesforce platform. It's up to the client as to how they wish to deploy it.

April, I want to move to you for a second because you came to Slack a little less than a year ago and it was, oh, just a humble million users now. Two plus million, I think. Right. And you guys have been an amazing story of platform getting adopted really quickly. And so on one hand, people love Slack, the product, you've obviously got a lot of users and then you've went all in on platform. And there's some people who would say, I love Slack because of everything that's on top of it. Do you think about those other two of Slack being this extending your functionality and is there a future where Slack exists as a mechanism to bring all these other great things to you and that becomes the primary purpose?

I would say the two aren't mutually exclusive. So we're hard at work every day making Slack the best communication tool for teams that helps them be more productive. And if we do that, that affords us the opportunity to be a place where teams want to get other tasks done and when they want to go get other things done at work. There are a lot of other tools out there. There's just a proliferation of SaaS applications out there and we want to help teams find the applications that will be best suited to their needs. And, and so that's why we launched the App Directory last December and we've started making it easier for developers to build on our platform and get their application in front of our audience of 2 million daily active users and growing. But we're not done. We're still extending. We've got a lot of improvements that we're going to be bringing to the core product that we offer within Slack. And the more that we can solve that communication challenge for teams, the more that we can actually help third party developers play into that critical communication layer. And the reason that I think that's really important is that communication is just so foundational to getting anything done at work. You can't, you know, there's hardly anything you can get done at work without communicating within your team. And so we're going to try to do that really well and create a great opportunity for developers to build into us so that they can solve all of the other problems at work. And there are an unlimited number of those. And we're really just getting started and bringing those developers to our platform.

A lot of times it'll come to you. A lot of times people come to these things and they see Slack, Dropbox and Salesforce and they're like, either really excited because you guys are amazing, or they're like, what the fuck does that have to do with me? I've got like 10 people using my product. They love it, but how do I think about platforms? April, I want to follow up with you because you came aboard to run platform, now you run all product there. What would have been too early for Slack in terms of pursuing a platform strategy? And so what impacted the timing of when you really poured gas on the fire? Put the pedal to the metal around platform.

Yeah. So my boss, Stuart Butterfield, one of our co founders at Slack, he shared a deck with me recently that he put together before the team even built the first version of Slack. And so there's been a vision for Slack to be this platform that serves as a command center that brings together all of the applications you use at work, really since the outset. So I wouldn't say it was sort of like we were doing one thing and then at some point it was like, okay, now let's pour some platform juice on top of this. It really is about. It really is such that Slack and Platform are one and the same. But we have definitely made more investments in it. So the team has grown from a handful of engineers that have built a lot of the early integrations with third party applications. So now we've got more than 60 folks. So, you know, probably 20% of the company roughly works on platform in some way at Slack, because we view it as such an important part of actually solving the fundamental problem that we're trying to solve for our users, which is to make their working lives better.

So the vision was set up, it was a choice of when to execute based upon other aspects of the business.

Yeah, I mean, we've only been around for two years, but we've definitely been putting more gas on it over the last, I'd say six to nine months.

So, Ilya, I want to shift to you because you're at Dropbox, you're at Index now you get to see a lot of different things. Platform's this magic word. And I Think a lot of people think it means somebody else will help me make money for my business. Right. And that given the law of numbers, if everybody does that, that doesn't work very well. So tell me a little bit about how you think about companies maturing into a platform when they're early, before they're a household name, so to speak.

Yeah, I think that's a really important point. I mean, I think I've seen a lot of pitch decks where there's a slide that says we're going to be a platform. And my kind of answer to that intuitively is actually that's probably not the right call for most companies. A company like Slack I think has the ingredients for what it takes to be a platform. And just to kind of give you a sense of how I think about platforms, platforms are really marketplaces. They connect customers who are your users with providers of applications and services who are third party developers. And the things that you need to make that platform work are a way to really make the two meet. Right. Whether it's an app store, but really you kind of want something inside the product that gives people access to core functionality of these applications, which I think Slack has. And something that when we were working on Dropbox in the early days, we frankly didn't have. And we built over time into the core UI of the application, the ability to access third party services. We actually did that with Microsoft Office as a first party app there. So you kind of have to have an interface that allows you to connect your users to applications. Then you need something that's actually valuable to developers. You need either data. In the case of Slack, it could be things like the conversations. In the case of Dropbox, it's the 35 billion office files that people have stored on Dropbox and other data that they've kind of put there. And potentially some APIs that make the developers lives easier. It could be quick ways to build UI ux. It could be better ways to store data and synchronize it. It could be something like, you know, Salesforce's case, sales data that they can't get to otherwise and integrations into the UI UX of Salesforce. But if you don't have those components and if you're not thinking about them right away, then it's not always necessary that you should build a platform. And I think, you know, you kind of have to draw the distinction between platforms and services. And I think in your analogy of names or characters in movies, Mr. Wolf in pulp Fiction is a service. He's not Really a platform, you need something dirty taken care of. He's the guy you call and he does that service really, really well. And you can provide that as an API to lots of folks who can build off of you. But investment in a platform is a really big commitment because you've got to make sure that the core application supports the platform. You can't just tack it on. You gotta make sure you build a really good team that will work with developers. You gotta figure out how you're gonna promote and how you're gonna monetize, you know, and you gotta make sure that if your platform evolves, you take care of your developers. So it's a pretty big commitment. The thing I'm excited about with Slack is that Slack itself has the Chrome and the UI UX to really be a platform. You can think of awesome things like bots and short commands and other UI UX elements inside of the main chrome of the app that will allow you to interact with applications and will actually allow developers to build more quickly in that environment. So that's kind of my perspective. So I think platforms are great and aspirational, but I don't think everybody should have a platform. The other thing I would say is that when you think about your customers, you know, selling a platform to somebody is. It sounds pretty cool, but it's a pretty nebulous thing to think about. When you're a customer and somebody says, hey, we're a platform, what does that really mean to you as a customer? You got to think of what are the value, the services, the applications, the functionality that the platform is going to provide to those users and really go with that. And if there's a way to extend your application and make it better and do things that you're not going to do yourself, like Mr. Wolfe, then you.

Should build a platform. That's a great transition, actually, to Neurocha, because Salesforce has been a platform in the platform business for as long as anyone in the cloud business. And early days. I explicitly remember your sales reps being very confused. They knew how to sell sales, and then platform was this imaginary box. It was the pixie dust of the time. How do you think about people now building on top of your platform, engaging in that conversation in terms of, is it for you? Is the platform for Salesforce today just a matter of defining the sum of all the apps that are on top of it, or do you still see that conflict inside of your own business? Is how you think about that two aspects of the vagueness of a platform versus the precision of an application, I.

Don'T know that there's a clean answer to that. And actually, when Mark was telling us about. And I've been at Salesforce six and a half years or so, so not the start of the platform, but when Mark, when Marc Benioff tells the story, he basically says, well, you know, we figured out that our customers wanted to configure the app, right? So instead of the tab saying, you know, sales and forecast and opportunity, they wanted to call it whatever their words were. And then he realized, well, once you do that configuration, then you can open it up and then let's be a platform, right? That pretty much was the Salesforce original thinking at the time. Not a whole lot of, you know, let's build an app exchange with 3,000 apps on it, right? It wasn't really quite that ambitious. So the start of it was very simple. It was like, oh, well, let's just open it up and see what happens. So it was, you know, again, kind of a. What we do is we have a very smart CEO who makes these decisions. Today, though, I think we're much more established, and we do see that if you go back to a sales rep having challenges expressing it. I think the concept of the platform being for our own apps, for your apps, for an ISV app has made it a little bit clearer in that we just treat our apps as one thing on our platform. So that's how we kind of distinguish between the two. And if you think about a platform and you have three things on top of it, that gives it a very tangible representation.

I want to read a quote, and it relates to somebody. Ilya, you and I were talking about yesterday. People respect success. They respect big. They don't even have to like your blank product. If you're big enough, people are drawn to you. Basically saying the reason all of you have been in successful companies with successful platforms is because your product was good. The rest is all bullshit, right? Like, until the product is good and has adoption, it doesn't matter how good your platform strategy is. You guys agree with that, disagree with that. Well, how do you think about the notion of drawing gravity to you before a platform is actually even conceivable?

I mean, you've got to have users. I mean, and I think that.

And that was Jay Z, by the way, just for.

Yes, well, so I think the question is, what is the foundation you're starting from? What problem are you solving? How large is the potential market for that? Very big market for CRM and all the things that Salesforce does. Communication is a huge market. Everybody needs every type of every function in every industry needs communication, file storage as well. Very, very broad problem. And so then the question is, you know, one of execution as to how well we Slack can solve that problem. So if communication is something that every single worker in every single company needs, if we can solve that problem well and can actually get a lot of those folks using Slack, then that means that the developer that wants to solve expense reporting or the developer that wants to build new dev tools can actually come to Slack, can use Slack as a distribution channel, can reach an audience of customers at work. And we've got real examples of this. I mean we've got teams of two to four engineers that are working on a new take on HR software. For example, a company called growbot that has actually gotten thousands of customers to use their app. And so you know the path to market for an enterprise application like that to just reach an audience through email, through other marketing channels. It's kind of a non starter for a lot of companies to really try these new applications. But when they discover them in Slack, they can actually experience the Slack experience for these apps and then potentially become paying customers for these companies. So it's very compelling. But you do need that user base, you need that distribution.

So distribution is great. Ilya, I'm going to ask you, since you're not at a company, you can be our voice of truth here. If I choose to build on Dropbox, Slack, Salesforce, am I giving up my own platform aspirations?

I don't think so. I mean, if you think about it, take Dropbox as an example, it was built on the Microsoft and the Apple platform, Right.

But that's as a technology, I'm saying from a distribution perspective now, I'm certainly giving some control away, right? Yeah.

Well, you basically want to target that set of users, right? So you kind of join a bigger platform. A good example of that were applications that ran on Facebook and used the Facebook graph to get distribution. You get on that train and you get on that big wave. And the question is, when you're riding one of these big waves, how do you get off? Sometimes the wave crushes you and sometimes you can have a good exit into parlaying that into your own platform. But I think the point that April made is really, really important, which is if you think about a SaaS business that's trying to get customers, you're spending thousands of thousands of dollars to acquire a lead. And I certainly see that in a lot of the companies we see and if you can find platforms like the Salesforce platform, like Slack, like anybody else who can actually give you access to an audience at a lower cost, that's huge. Now to do that you need scale because you need to reach the millions of knowledge workers, figure out which companies they're in, figure out which services they might want to use. And I think if you can build a platform that does that, you'll really revolutionize how people actually go to market in SaaS and in enterprise. Now the question then is, how dependent are you on a Slack or a Salesforce for your long term success? I think the answer there is it really depends on what you're building. If you're building a derivative thing that the platform itself will want to own, you're probably at a bit of a risk. And that's kind of what we look for. We look for companies that are doing something that's very adjacent, that's not going to get crushed by the main platform immediately and that'll have time to grow. So I think the biggest thing is joining a platform like that is really knowing the kind of social contract you have with them and joining one that's really, really transparent, because I think that's the main thing.

So I want to come back later to the ecosystem perspective, but want to move for a second to, all right, I got a company, I got a bunch of users now, right? And I want to start this notion of having a platform strategy. Naracha, maybe you can start what are the prerequisites of advice you would give me that I need to put in place beyond that to have a successful platform strategy to create an ecosystem around me?

I think a lot of what Ilya was saying makes perfect sense, right? It's what are you adjacent to what makes sense? But if you want to go your own way on a platform, you do you start that or do you start with APIs and you start kind of drawing a base in? I would probably ramp into it a little. I do think it's a little aspirational and grandiose to say, okay, I have some users and now I'm a platform. But the data, if your data is valuable to a certain set of users and you start with API access, that's a good way to just kind of get a sense of what your ecosystem would be. How could you work with them, what kind of partnerships that you might form? And that seems to be a way to just test the market. Because I do think that if you do come out and you say, well, I'm a platform, you know, can you say that legitimately?

So I've got an API, I've got a bunch of users. What's important, April, maybe for you, from a business alignment perspective, what do I need to get the pieces around that to make sure that I've got the best chance of success around my platform?

You need to solve a. You need to be aiming to solve a big problem. And, and so if you're aiming to solve a big problem, you do that in a way that leaves users really excited about your product, using it frequently, then that affords you the opportunity to be able to expose access to that audience and actually allow other folks to plug into a platform. But I think that there are. I would just say that there are. There are many big problems in the world and in the workplace, but there are a distinct number of problems that I think are so foundational that they're the type of products that customers are coming back to use every single day. And I do think that that is pretty much a requirement to be able to build a really meaningful platform.

You guys are either the best or worst example because your timeline was so compressed. I don't know if it's like we're going to learn a lot from that, or let's just put it to the side because it's such an anomaly. But were there differences in terms of roles or people or things that you had to start doing to get those first couple partners? I'm sure you had people wanting to build on. What were the first couple stories that you really kind of said, all right, this has taught us some nuance on how we want to pursue this.

Yeah, I mean, I would say that it goes back a little bit to sort of the genesis of the Slack product, which is that the Slack product was born out of a communication tool built by the founders that was used amongst a team to solve their own problem. They couldn't find a communication tool that they loved, and so they ended up building this great thing that now we know is Slack. And so I obviously wasn't around in those days, but I think that approach to product development has certainly remained and it actually guided the early days of the product, which were, what are the tools we're using every day and how could we integrate those more tightly with the Slack experience? So integrating with GitHub and Jenkins on the developer side and integrating with just a variety of other tools like Google Drive and Box and Dropbox that were everyday applications that, that the team was using and that our customers were using, that was a great foundation. And so what we're really transitioning towards is abstracting that and identifying those common patterns which are that apps want to push notifications into Slack because that's significantly better than sending an email out to a bunch of people where they then have to sort of reconstruct the audience that needs to discuss it to be able to hash through things and get to a resolution. People want to be able to perform small tasks from within Slack, they don't want to do everything in an application. You're not going to actually write code from within Slack, but you might want to be able to give feedback on a code snippet from within Slack and making it easy to do that with slash command. So starting to abstract those patterns and now make those available to third party developers with some guidance so that they can understand how to do this in a self service way. Because the demand from our customers and the opportunity now exceeds our ability to to ever be able to keep up by just doing these one by one. Which is how we've really made that transition into now operating more like a true platform. But it started with building a lot of the early integrations that a lot of teams use every day in large part ourselves.

So I think that's actually a super important point and I think Slack really nailed that. The feedback I give to most folks is you should really think about a platform. So first of all, when you think about a platform, you should think about really hand holding or building the first experience experiences yourself. Because you just can't rely on a third party developer ecosystem to build something awesome and magical. Sometimes it happens, but really very infrequently. So you gotta build some of those early integrations yourself with a partner in mind and make them extremely high quality because that's what's gonna really catalyze the whole ecosystem. And the other part of it is that you know these applications because most people basically say, hey, we're gonna have a platform and like, you know, the world will happen to us. Like we'll get hundreds of thousands of developers, they'll build everything. The reality is like you have to be very, very thoughtful about whether there are applications and services that actually make sense on your platform. Do they make sense to your customers and users? Are there things that you wish you had that your customers are asking for, but you actually just don't want to build. They might not be interesting, they might not be high enough roi, they might not be valuable enough for you. Those are the things you should go find a third party to go build on your platform and turn your Experience into a platform. If you think about Windows as a platform, think about the early days where people built spreadsheets and document editing software, which eventually Microsoft actually absorbed in a smart way. But the reality is the initial experience your users have with your platform has to make sense for your product and, and has to be highly curated.

And so I've been spending a bunch of time in healthcare recently. And in Healthcare, there was an app that made some claims. The FDA basically filed a lawsuit against them. Cause they couldn't justify their claim scientifically. If that happened in this room, we might have some problems. Right. There's a different bar. What's the bar? Narajan, this is a good place for you to talk about Salesforce. What's the bar in responsibility for the provider of the platform to ensure quality for their customers? How do you kind of go between buyer beware and. And an open marketplace? How do you navigate that spectrum? Because I know Salesforce has had lots of iterations of that over the past decade.

Yeah, that bar is unbelievably high. So we, you know, I talked about trust and kind of Jon Stewart earlier. That is a big value. You know, Salesforce has been in cloud for a long time. And the biggest thing that we focus on is trust, because once that's eroded, you know, it kind of puts a lot of everything else in jeopardy. So for us, it is that trust, that security review, you're putting it into the Salesforce environment. It really matters to us. So to be very, very honest, we. We get a lot of ISVs saying, you got to get me through the process faster. And we say, well, we could, but that's. That's not really what we're about. So I think the bar is pretty high. And when I speak to customers, customers look at me and they say, yeah, I know that's an isv, but it's on Salesforce. So you are responsible, you are the platform, and we count on you. So with that comes that, you know that burden.

And do you feel like. I'll ask the other two, because I know Salesforce monetizes people building on their platform directly. Dropbox, Slack.

Dropbox, at least to my knowledge, is not directly monetized.

April Slack.

Not yet.

So do you feel like that changes the bar? I think on Slack, I signed up, it says we're not endorsing any of the products, but it also says to the product manufacturer, don't spell stuff wrong because it confuses the user. So you care about your user experience, obviously. How do you guys draw the line of how High the bar should be for the apps that are wanting to be part of your ecosystem.

I mean, so it's sort of a two prong approach. We have an open API. Anybody can build on top of the API. You know, thousands and thousands of developers have, as well as some customers have. Actually many of our customers integrate with the API to build their own custom integrations and really tailor fit Slack to their own workflows. You know, use Slack as the interface to their own data internal reporting tools. So there's a lot of really great things that are benefits of the fact that we have an open API. You don't have to call us to, you know, get permission to use our API. But our App Directory is a point at which we actually, we review every app and we try it out, we make sure it does what it says it will on the label, we give feedback in terms of, you know, the experience, how the app is described, how the developer's using the API. And so we actually take a very, very hands on approach to giving feedback and we want that to be a collaborative process. We want the developers to be able to put their best foot forward and we certainly want to make sure customers have an awesome experience using Slack and so we want to avoid anything that could degrade that. So we take a very, very hands on approach to approving the apps that show up in the App directory while maintaining that open API.

All of you have. I'll come. All of you have also this, hey, we can change the terms of service anytime we want or something to that extent, right? If you are a platform provider, you're going to make those changes and that's just reality. How do you make those changes? How do you change the rules for people who are building their businesses on top of you in a considered meaningful way without breaking that trust.

Gently? No, I mean, I think you have to be very transparent with the developer base and I think the more transparent you are, the better up front. I mean, Dropbox is always said, hey, you know, we're not going to shut down derivative apps that are sort of Dropbox like, but it's probably not a good idea for you to build one. And Dropbox has recently phased out a bunch of APIs, which I think they did very well in sort of giving developers heads up, giving them a lot of time to transition their applications. It's really mostly about communication at the end of the day and frankly it's about picking the, the things you really want to do in the first place. Right. So do you really need a particular API? For the success of your platform, you have to be very thoughtful about that, because once people start using these APIs, it's really kind of hard to get them off. And it's somebody's livelihood, it's somebody's application that they're using to support their users. So phasing things out is painful. That's why I think you have to be very, very thoughtful about what you build in the first place.

So I'm going to. So there's other companies that are not being up here, so I'll pick on them that have had a bad reputation or problem. Twitter, LinkedIn are two that have been thought of as changing the rules on the developer ecosystems. Now, you don't have to comment on them specifically, but what do you think creates clarity in that relationship in terms of, is it your own strategy in understanding it? Is it being able to expect what's around the corner? You were at one of those companies. How do you think about creating the right environment?

Yeah, I mean, I think we started to be really transparent and clear about our overall strategy. Like, what is Slack? What is it for? What is our business strategy? And we build a communication tool for teams and we sell it for seats in a SaaS model, and that's pretty straightforward. And having worked at a consumer company, I was at Twitter for five years, I think that there are just a different set of challenges that come with operating a platform while also being a consumer, consumer company that monetizes through advertising that are just. They're just not relevant to everything we're talking about today. Everyone here is we're solving problems for teams at work. And I'd say the incentives are very, very well aligned. There's the technical aspects of, like, what if you change this API endpoint and that sort of stuff. And I think communication is certainly the answer, which is why I'm staffing up development, developer relations and partnerships folks, so that we actually have people that are really, really focused on providing that guidance. But, you know, I think that the guidance I give to developers who ask me this question of, like, how do I know you're not going to build this feature is that, you know, if the end goal for what you're building is to make using Slack better, and that would be true for any other platform, if the end goal of what you're building is to make the platform you're working on better, then my recommendation is to think more broadly and to try to solve a broader problem than just trying to make the experience of working on that platform itself a little bit Better. I think that's just, you know, I'm also an investor as well and that's the guidance that I would give any company that, you know, I would invest in. And I think that that that sets us all up to solve, you know, many of the myriad problems that exist for teams at work and for Slack to be able to provide that distribution channel for the those teams in a way that is going to be very symbiotic and provide a lot of value to them over the long run.

And the one thing I would add to what April said is that symbiosis is the key to the relationship. So if you look at Salesforce, AppExchange has been around for 10 years and we have over the years changed the terms gently, as Ilya said. But realizing that it is a symbiotic relationship and part of the success of Salesforce has been the enthusiasm of the developer base, the enthusiasm of the customer base and just that shared sense of purpose. And that's an essence to the relationship that we can't lose.

So Nira, you guys have a unique situation in that you're directly charging people for the platform and semi transparently like it's. I think you've talked about it publicly though. It's not sitting on the website. How does that change?

It's actually sitting on a website somewhere.

It is sitting on. The percentages now are sitting on the website. Website. How does that process of charging partners change the dynamics? And I'm thinking of, in terms of, think about this in terms of not just Salesforce but the advice you would give somebody else who wants to charge somebody basically access to their customers particularly and second order potentially their technology. How does that change the dynamic of the relationship? What are the things that you think are additionally needed because of that direct financial relationship with the partner?

Well, to your earlier point, the bar is higher. If you're trying to monetize, then the obligation becomes much, much more. And I think that that's the nature of the relationship, that there are expectations set when revenue is involved that we have to deliver to. So it's not a, you know, the platform can't go down. We can't, you know, we can't just like arbitrarily change things. When people's livelihood and our shared interest with, you know, revenue sharing comes together, that's basically it. That's why the bar is higher for security review. That's why the bar is higher in general. So I do think the obligation, it is still symbiotic. The deeply, deeply symbiotic relationship, but that obligation to each other is ratcheted up.

Ilya, if you were talking about Dropbox or Slack, what guidance would you give them on if and when they should think about directly monetizing their platforms?

Yeah, tell me, what do you think?

Tomorrow I would say that I would figure out a model for distribution and really understand the dynamics of how application providers connect with their customers. Charging for a platform is tricky. I mean, it's worth doing it when you're really giving people a lot of access to a lot of customers. And it does allow you to sort of filter out apps that are not really serious. That's kind of the other piece of it is if you have to have some skin in the game, people usually do a better job. But I'd really make sure you can get somebody a guaranteed number of users within a certain amount of time by doing certain things, whether it's promoting in product, whether it's promoting via email and other channels. And I think once you can kind of create this ecosystem that connects users and applications, then in my view, it's pretty fair to charge a tax. The only other kind of perspective on this would be, are you giving people access to some data that they really need to run their business and, and can't have access to otherwise? But I don't think in either case that's really so true. It's really mostly about, can you truthfully tell a developer, hey, by joining our platform, we're going to get you in front of the kinds of users that you want to get to. And really the simple math is you could go spend 1000 bucks a customer on AdWords, or you can join our platform and pay a little tax. That would be my advice.

Thank you. You buy that, April?

Yeah. I mean, I think that all that's all totally reasonable. And I also think that at Slack, we're even still at a stage of just making sure that people can find the apps that will help make Slack a better experience for them, that they can understand how to use them. And we're really focused on that discovery piece and just getting the user experience right. And then I think the more that we do that, that affords us the opportunity to really think about what we want to do to help developers to be able to build a business on top of Slack. And we're already hearing demand from it. I mean, since we've launched the App Directory, we've had developers directly ask us, like, you've already got the credit card info. Can you just charge people for us? So, you know, I mean, I have no doubt that that opportunity is there and it will be something that we think about over time. But we're going to keep the bar really high of making sure that we sort of check the box of is this the right experience for our customers first before we, you know, really delve further into that. Because there's a lot of complexity that does come along with that. Even though it's an exciting opportunity.

We have a few minutes left and I want to basically get from each of you, particularly 2016, relevant or in general, what's one misconception you see people talking about when they think about their own platform strategy, not your platforms, but their own aspirations around platform that you want to call out. What's one misconception? That you're like, don't follow that advice. That's just wrong. It will take you into a dead end.

If you build it, they're not going to come. That's the biggest one. And I think you really, it goes back to the earlier point, but I think you really have to have something unique that's a distribution channel or proprietary data that's really valuable for creating novel experiences. Just building a platform and saying, hey world, we have a platform isn't going to get you a whole lot of real value. Yeah.

And it's harder than you think it is to make it work.

Neeraji, you think people diminish the difficulty of actually pursuing a platform strategy?

Yes. Not just from the kind of the marketplace dynamics like what data or users can you offer, but just technologically building that thing and getting it evolved and making sure that it satisfies so many constituencies. It's a tremendous amount.

It's really in some ways the equivalent of having kind of another sales and go to market team. If you think about developers, you have the long tail that's kind of like your inbound, you have the mid tail developers, that's your kind of mid, you know, inside sales. And then you have, you know, large partners that's going to be an enterprise team. All of that has to have, you know, customer support. It has to have high touch at the enterprise, low touch at the long tail. You got to have marketing behind it. So, you know, really supporting a platform is a pretty, it's like duplicating a serious size of serious part of your company.

I mean the one that I would call out is I think there can be a misconception that it's a zero sum game, that if you, that if your company has platform aspirations that there is not a role for you to also participate on other platforms. I think if we look at the mobile platforms, for example, you know, for a long time, Google, for example, didn't invest heavily in apps on the iOS platform because they had their own aspirations. And then now they've built great apps on top of of the Apple platform. I use them every day and I think that's been a really smart decision for them. And so, you know, we spend a lot of time talking to companies that are also pursuing platform aspirations. And I believe that, you know, there are customers that are in slack for like 10 hours a day, more than 2 hours active time, but connected to Slack 10 hours per day. So I would imagine almost any company building for teams at work, no matter how large they are, actually is a meaningful opportunity by having a great experience, experience on Slack, even while they pursue their own opportunities as a platform.

I said with the last question, but now I'm lying because you brought up something else. So I've got a great idea for an app that's gonna help salespeople build really complex proposals better and that needs collaboration. And I need data from Salesforce and we have a lot of really big files. But Niracha's gonna charge me. April said she might charge me. Iliad said Dropbox might charge. What the fuck do I do? Like, what am I? Am I, am I? How should I be thinking about that? When these multiple platforms come together versus is there some, you know, is there direct connections that platforms will start to make between amongst yourselves that will make that easier from the person who wants to build on the shoulders of giants.

Potentially. It sounds like a good idea. I mean, it's already the case that I think there are developers out there that are tight tying together these different applications. And so then it's just a. It's sort of a competition among the distribution channels. Although that's not really what we're focused on right now at Slack. But I'd imagine over time, you know, if there are multiple marketplaces where teams are discovering apps for work, then there will be some competition there in terms of, you know, we'll all want to be able to give developers the most access to great customers. But I think for now, you know, it's pretty greenfield, and I think that there's a lot of opportunities before. Before people really have to worry about that being a real point of friction for them.

Strike while you can. It might get harder.

What's that?

I said strike while you can because it might get harder.

Well, but the reality is when you're building on, if you look at the big mobile platforms, if you're a serious application that's targeting a big global audience, you've got to build on the core platforms and some of them offer different things. Android is very different than iOS in many ways because of the amount of access you get to the actual underlying underlying os. The same way that I imagine you can build the sales app for the sales guy that's gonna send nice notifications to Slack where they get to see them in real time and then they'll pull data from Salesforce and maybe attach some of the records from Dropbox. Right. So I think you can really tailor the experience to the platform that you get engagement on Racha.

Any last words on that?

I would say look for more platform integration in the future.

I'm going to end with a quote from Jay Z again. He's like, I'm not a businessman, I'm a businessman and I think that applies to platforms. I want to thank our panel very much. April, Ilya and Niracha, thank you so much for your participation. Before you guys get up and go, you can get There's a happy hour following this, so go outside and surprise, surprise, there's free drinks and then the epic. I'm promised it's going to be an imperial level after party at 10:15. Folsom starts after the happy hour at 6, and I think you got some emails suggesting Ubering down public transportation to get there, but it'll be an awesome, awesome event. I will definitely be there and I know many of our panelists will as well. So thanks everybody.