Scaling Revenue via Indirect Channels and Platform Ecosystems

Hello everyone, how's SaaStr going? All right, that was quiet. Well, we wanted this to be a really intimate and interactive session, so in order for us to do that, we wanted to poll the audience. We can't really see you very well, so we're gonna need you to clap in response to my questions.

So, you know, we've got a big bet riding on—

we have a big bet riding on this.

There's a free cup of coffee in the green room riding on this bet.

Yes, so here you have represented Stripe, Box, and Slack. So we wanted to poll you, who uses Box for their work? So if you use Box, clap.

Okay.

All right, solid. If you use Stripe.

Oh, wow, okay. Yeah.

And I'm being really self-serving right now. If you use Slack. Yeah! All right, well the bet panned out in my favor. I'm very, very lucky.

I think we called the first one, but not the second and third.

Yeah, we didn't call the second or third. So thanks everybody. Well, to kick things off and help you understand how this panel is going to work, it's a little bit unusual. I'm going to be both moderating and participating. You can create whatever combined word you'd like for that to be the case. Um, and we'd like to just start with quick intros to tell you why we are qualified to talk about scaling revenue via platform and ecosystem. Ecosystems. So Vicky, if you give us your intro.

Great. Thank you, Cici. So I'm Vicky Lin. I have been at Stripe for about 4 years. For those of you who did not clap, Stripe is a set of developer APIs that help businesses accept payments online and do all sorts of innovative things in moving money in the cloud. Uh, and Stripe's ecosystem is quite large and thriving. We're really proud of it and want to do more with it, of course. But we have about a couple thousand partners in our ecosystem today helping bring businesses onto Stripe through their platforms or extending the Stripe functionality once customers have a Stripe account.

Great. And Neil?

Yeah, so Neil Wall, and I've been at Box for 6 years. I presume hopefully most people know who Box is. We're a cloud content management platform, and I have a number of different roles, but The way we build or think about our ecosystem is how do we help or work with partners to differentiate our solutions, and how do we actually work with partners to reach new customers. So on the differentiate, we have about 1,400 companies who've— ISVs, or companies who've built or embedded Box as a content layer into their applications. And then on the go-to-market side, just over 40% of new ARR comes indirectly around the world through partners. And I'm happy to talk about both of those as we go through the session.

Awesome. And I'm Cece Stahlsmith. I run platform marketing at Slack. I've been doing that for 3.5 years, so I got to join before we launched our platform, launch it and scale it from there. We have over 1,500 apps listed in our app directory, so those are with third-party partners. We also have a lot of developers who build with our API just for their own Slack workspaces as customers. And 90% of our paying customers actively use apps in a given week. For some context as well, I actually worked with Neil when I was at Box back in the day as a founding member of the platform team there. And then also went into venture capital where I invested in API-first products. So, we want to, to, oh, here's who we are and we wanted to show you how our logos have changed over the years. Slack's being very recent. So we want to help you think about, all right, I'm probably a SaaS product. If I'm sitting in this room, it is SaaS-ter. How do I think about whether or not I have the opportunity to build a platform or an ecosystem? So we want to get to practical getting started tips. We're going to go back in this exact same order. We'll try and keep it a little fresh. But Vicki, can you tell us how to think about getting started with building a platform or an ecosystem?

Yeah. At Stripe, we're really fortunate because I think one of the first things you have to do when you want to build an ecosystem is focus on developers and APIs. And because that was such a core part of Stripe's DNA from the very beginning, it was almost— it was completely a natural decision to really focus on our ecosystem. What's a couple of things we did early on that I think were very successful were, you know, we provided zero friction in actually getting started with Stripe. Even today, all you have to give us is an email address and you can access Stripe's APIs. You can get up and running as a platform and you can be onboarding customers almost immediately. We also didn't even ask people what they were trying to do. We didn't worry too much about are you trying to bill for your own SaaS product or are you actually trying to integrate Stripe to offer to your customers? It really actually in the early days didn't matter. Now as we start to scale, it matters increasingly more because we want to help support different use cases. But in the early days, we really just wanted to get traction and get developers up and running. Awesome.

Yeah, and at Box, it was a similar type of story. We— Box started as a consumer file-sharing company, and we quickly learned that that's a tough market to be in. So about a decade ago, we pivoted to focus on the enterprise. But in order to get the flywheel started, we always had this notion of for shadow IT, we wanted to be one of those rogue apps that users were bringing into the enterprise so that to get their work done. So we, we always had this kind of weird dynamic with freemium where we would just give away 50 gigs for free, if you remember that.

So, yeah, I still have that.

Yeah, exactly.

Shut down recently.

And, and we, we, but we learned that that's kind of expensive. Like, you can, you want to be relevant to a certain point and And once you have a minimum viable relevancy, if you will, then you've got to pivot and focus on the things that are actually relevant. So we actually did that. And it was maybe controversial at the time because we were spending a lot of money serving the free accounts of the users. But that was super important because it allowed us to be one of the top apps that were being brought into the enterprise. And then we can use the security and compliance and control that IT would actually buy into to control those accounts. So that's how we got started in building our ecosystem.

Cool. I actually got to build Box's early ecosystem with Neil, so there's some extra fun stories there that we might go into. So the thing that I am really passionate about, I've done this a couple times at different companies, is figuring out how to build a platform flywheel. So what you see up here is a very simple flywheel. On one half of it, you have product market fit, and on the other half, you have partners partners and ideally developers integrating in order to reach your users. So the platform flywheel, the basics of it are you have a product that suddenly has market fit, you have customers who are joining that product. A developer or partner will see that product and say, hey, they have a lot of users. If I integrate with them, I'm going to get users, or I'm going to be able to use that tool very effectively for my product. And then you get demand from partners and developers, and once that demand kicks up, They integrate, they build useful things on your product, and suddenly your product is more useful. So if you look at the case of Slack, we actually built our first 80 integrations ourself in-house. So our platform wasn't originally built for external developers to build for all of our customers. It was built for our customers to build for themselves and for our customers to use the integrations that we built ourselves for them. This went really, really well. We saw wild product market fit with our integrations. So much so that developers and partners were just banging down the doors to get access to our APIs, which weren't built for them to be using at the time. So when we launched our platform, we actually were taking our APIs and making them consumable to third parties for distribution on an app directory. And we've just seen a lot of growth and success of the platform since then.

So I have a question on that one for both of you is if you think back to the time when you're trying to convince your engineering team to invest in those first 80 apps, or back when Stripe were actually trying to create the APIs, what was the dynamic, and what did you learn from that in terms of the alignment with the need to build an ecosystem with the scarce resources in engineering to actually go do that?

Yeah, I'd say at Slack it was quite easy to convince, because a lot of people think some of our very early days, like 2013, 2013, 2014 growth was due in part to integrations. So because we were seeing so much pickup of them, it was very obvious like we needed people to be able to build more integrations on us. So it was, it was very easy to make that case. And we still to date have a, I lead a whole platform marketing team. We have a pretty significant platform team in-house. So the demand for fighting for resources for platform wasn't hard. Whereas at Box, I know it's been different. So you wanna speak to that?

Yeah, I mean, that's it, because I think earlier stage companies are always— well, every company is resource constrained, but especially when you're at the very beginning. And the notion of what might happen in the future when you get an ecosystem, everybody— many people will see the benefit at scale of getting to a platform and then getting the flywheel going. But the very, very beginning, it's important that you think about what is the alignment with your engineering leaders and the senior leadership team on what the company is trying to accomplish, and then stick with it. We, I mean, when we're doing the One Cloud, like, there was always this debate about do we build out APIs, do we do the integrations, or do we do it ourselves, or do we let other people do it?

Well, I think that gets really well to something that's on our sort of second slide here, which is how do you measure whether or not an ecosystem is actually paying off for you? For your business. So I think that that's the number one thing. As I'm sort of referring to with Slack, we just had so many customers using these integrations and saying they're really valuable to them, we knew that it was making our product stickier to have really good integrations with the products that our customers use every day with Slack. How do you think about measuring the value of your ecosystem?

Yeah, I mean, I think the key is you don't build an ecosystem to build an ecosystem, right? You really ultimately have to be solving a business, or like a compelling business problem that is existential to your company, and the ecosystem just happens to be the most effective tool lever to do that. For Stripe, again, we are— we're— our core product's an API. You cannot use our product unless you code. But of course, there's, you know, millions of businesses out there that want to accept payments online, and so it was a natural extension for us just just to focus on our user, which in many cases are partners who are integrating Stripe to offer to their customers. So for us, it was never like, we are going to build an ecosystem, what should we do? It was, here's a real problem that our users, our partners, are facing, um, in that they want to onboard their customers, they want to make it easy for their customers to accept payments and manage their payments once they're up running. And so that's the problem we solved. And that makes measuring value easier because you've already identified what business challenge you're tackling.

Perfect. And if you see this graph, it's not question marks because we didn't complete the slide. It's what does— what are you measuring in terms of your platform success? So one of the ways you can measure platform success is how many people are adopting integrations. For Stripe, it's how many partners are asking for this value. How do you measure platform success at Box?

So we, we do it in two ways. One is on the differentiate dimension, we measure IWOUs, so integration weekly active users. So the lifeblood of many SaaS businesses is, are people using the products that we're shipping? In our case, we actually measure when we ship a new update. So for instance, we integrate with Slack. We want to make sure that Slack is being used for collaboration, Box is the content layer for that. And we've done the instrumentation to measure that. Candidly, it's sometimes harder to show cause and effect. When you push a product, it takes a long time for customers to actually understand and then change their behaviors. But over time, we have pretty good longitude data on Iwow. And then on the other side, we do measure, I mean, because we, use an ecosystem to reach new customers around the world and different types of partners. We look at ARR. I mean, that's a— and we've— if we want to go deeper in this, we can, but we actually look at things like the relative— the average seat price net of margin for a channel partner versus direct. We look at things like, do we— the, the net new logos versus upsells or cross-sells coming from channel versus direct. And they're actually things that we pay close attention to.

Yeah. Yeah. Great. One other thing I would add here, if you're really practically trying to figure out how do I measure and scale a platform or an ecosystem, the same way that you're building a funnel for your sales team, you can build a funnel for your platform. So the very, very simple way to think about a platform funnel is at the top, you're going to think about your partners and developers. How many people are interested in building on my platform? You should count them and then you should look at them and say, if I'm managing them lightly, you only need one person in the early days to really be working and interfacing with this group. That could be a BD person, that could be a DevRel person. You're going to say, okay, I'm engaged with this many people. That's like the next step down in my funnel. If they're engaged, then they're building. And after they're building, if you have something where you're going to publish an integration or something of that sort, there's a marketplace for Stripe. Same for Box, same for Slack. We have a directory of apps. So publish in the directory, the next step, is the next step. And then the bottom half of the funnel is where customers actually discover and then actively adopt and then use those integrations themselves. So it's a very simple kind of standard funnel, but a lot of the time in businesses, I've worked in platforms for a long time, a lot of the time people actually don't think to just straight up build that funnel and have a dashboard to look at the health of your ecosystem overall.

[FOREIGN LANGUAGE] To add on to that, I think once you start to get some of those integrations live, I think we all know who our best customers are. And so one thing we have done is looked at, okay, who are our highest value customers and what percentage of them are using one or more integrations? Is that measurably contributing to their stickiness on Stripe and their experience on Stripe? And if that's positive, again, as you get more mature, you can tie it to, renewal rates or ability to upsell, cross-sell. But even the early days, from a qualitative standpoint, you will have an early directional signal of, like, are my most valuable customers actually using these integrations or not?

So given that, do you change now that— because we struggle with this a little bit at Box. Now that you've gotten some flywheel going, when you think about the needs of the most valuable customers versus the long tail. I mean, how do you make those decisions? Do you build like the APIs or the APIs irrespective of which type of category of partner or ecosystem partner is actually going to use them? Or do you actually have a— whether it's the go-to-market or the tools or the way you treat them or the way you think about them, how do you make sure that you don't lose sight of the long tail?

Such a good question. And now that we are in a quiet period, it's a little hard for me to figure out how to answer it without sharing things I'm not supposed to anymore.

Oh, come on.

I know. Let me think for a second.

All right.

I think actually at Box, you had to cut losses here and think about where to focus platform. So do you want to speak to that first? And then I'm going to calculate a really safe answer in my head.

Yeah, so we built a partner program to help scale the long tail. But most of our energy is going— really 20, 30 apps that most people use day in and day out that we— our customers are saying, hey, I need you to integrate with this line of business app in this particular way. And that is consuming a lot of our resources. But what we do is we build everything with a platform-first mentality. And so it's API first, even for our own services that are being consumed in new products that we are building. But so that's it. That would be a kind of best practice here, is to just make sure that you don't deviate your APIs irrespective of the type of partner. But yeah, we struggle with this, candidly, because, you know, the 1,399th partner is not going to get the same attention as a Slack integration.

Yeah, so this is something I'd be curious to hear the Stripe thought too. So at I mentioned we have 1,500, over 1,500 apps in our directory, and obviously you're going to have some that are some of the biggest SaaS products in the world, and some that are more long-tail products. Our hope when we launched the platform, and you can actually look up this blog post, it's one of the proudest things that I've done at Slack, it's about releasing our platform roadmap. We did that back in the day after we launched, and we said, "Hey, we're building a platform, and our belief for our platform is that," that for us to succeed, the value of everything built on our platform in sum should be greater than the value of Slack by itself. That to me is a, it's actually from Bill Gates, but it's the definition of a really successful platform. That the stuff on top of you, built on top of you in sum, is greater than you by yourself. So we're on that path, and in order to succeed down that path, you really need to have both the head, like the really big companies that you've obviously heard of integrated and available to your customers, and a successful long tail. Making your long tail successful, I think you basically just have to have a really strong business development team that's going to work in with them, figure out who's finding good product market fit, and then helping sort of usher them into success with your customers, whether that's through more just growth strategies for them or introducing them into the sales process. There's ways to bring a couple of your more long tail players up and along with you. We have the Slack Fund in part to help do this. What are your thoughts on this one?

Yeah, I think the strategy is very different depending on the size of customer you're targeting. And for Stripe, we started with startups and founders and entrepreneurs, but we are rapidly moving upmarket and have increasingly mid-market and enterprise customers. So I actually think we are starting to do slightly different things depending on what the core customer set needs. Obviously, you have to, it all has to make sense collectively on your product, the overall product experience, but I think frankly what an enterprise needs for their ecosystem partners and integrations is very different than a startup. One of our most popular integrations is with Slack right now, right? But that's a startup-oriented integration. It is not an enterprise integration.

Yeah, yeah, I think one of the really interesting things here, I was in venture capital before this as an investor, and one of the reasons I was most excited to go to Slack for, to work on platform is the opportunity for those longer tail companies to grow on your platform is an exciting one. So I think that, I don't know, for me, any platform where you can see someone who's gonna build a startup on your platform, ideally integrate with other things too, but be able to grow and become a significant or bigger company, I just, I love providing that opportunity, and that's something I'm really excited about still about the future of our platform in particular, and you can look at companies like Guru and Workday, or not Workday, WorkRamp, if you've heard of WorkRamp, and Troops, they're all companies that have grown up on with us as a Slack platform company, and I think they have really exciting futures. So one thing that'd be fun to talk about are pitfalls. So we've had a little bit of prep call conversation. Vicki, what are some of the trap doors or things to avoid when you're building a platform?

Yeah, I mean, I really, the main rule rule, I think, is to try to avoid trapdoor decisions at all possible. So give yourself optionality, again, especially in the early days. And I still feel like a lot of what Stripe is doing too is in the early days. And, um, and these are like very tactical things. Like, uh, we rolled out, uh, our first kind of official partner program over the summer, and one of the hardest decisions actually was naming Right. Like, what do you name a partner who's in the program? And so we were, we were conservative, I think we and we what we did not do is we did not put in like a goal. You weren't a gold partner because one of the things of naming, you know, providing kind of gold, silver, bronze in your program is like, then what happens 2 years from now when you want to add another, like add another tier, like platinum, better than gold. Platinum. Platinum better than gold. So we, you know, we wrote for naming, we sort of said, okay, the first thing we're gonna go out with is you are a verified partner. You know, verified, it's, it's, it's not the flashiest thing for sure, and from a marketing perspective, it's, it's not— doesn't kind of inspire, you know, the hordes to sign up to be a verified partner. But it, but it's descriptive, it's accurate, and it gives us future optionality as we want to layer in benefits and layer in higher requirements that we can tweak the naming without having to go back to our verified partners and say, you are no longer the gold tier. You are now the silver tier.

Neil, what are some of the pitfalls?

A couple of them. And I think that this sounds weird, but a pitfall is assume that you're going to be successful and then work back from that. And you don't always do that. And what I mean, I'll give you a couple of examples. Back in the— this is a long time ago, but when I joined Box, one of the things that we were thinking about is, do we give a free version of Box to every mobile device in the Android ecosystem? That was a big decision. And we fortunately did not do that. But that would have been— because we assumed we were going to be successful in doing so, i.e., lots of people would start using the product. But that actually would have been difficult to, to scale the business, right? And then on the other side, on the go-to-market side, we have been fortunate in building consistency of terms and conditions in our partner, our channel programs, so that a channel partner in Japan will get the exact same structural benefits as a channel partner in, you know, in Europe. Or in other geographies around the world. And so we were actually fortunate in— it's maybe not a pitfall as much as a— we assumed we're going to be successful, and therefore we were able to avoid catastrophic, hey, we have to change the terms and conditions of a partner program while you have a bunch of customers already come through that channel partner. So I would just assume every company here, you're going to be wildly successful and then make decisions on that basis.

It's funny because I actually think in building out your processes and tooling, you should actually assume that you are not gonna be successful. I think one of the key things that we did early on was be willing to just throw some manual process at the, at the entire partner experience. So you partners would give us their information through a typed form form, right? We didn't have a partner portal. We didn't really have a very rigorous vetting of what your integration requirements were going to be— should be to be on our gallery.

Uh, was that— if you, um, were the contracts the same with each partner and just the processes by which you manage those different, or was it actually you're just trying lots of different things iteratively with each of the types of partners on the contractor, the business model construct itself?

Yeah, the, like, the core relationship with partners was the same. It just, we didn't invest a lot in the backend tooling and the processes to scale because we weren't quite sure, like, how many partners are gonna want to be on our partner gallery. Are customers gonna find value in that partner gallery? You don't want to spend 6 months building out entire partner backend infrastructure if you don't know know for sure that this is the thing that is going to be successful. It could be a completely different thing.

Having done this a couple of times, your partner app directory is the thing that you're always going to be like, ugh, I wish it was better, but you can't get resources to make it better because it's just like, is it high enough priority? We should probably ship this other feature above it. It always slips. That happened again and again at Vox. We were really trying to launch the platform fast when I got to Slack. We actually also kind of like for the first version of our app directory built on Airtable, like just to get it out, it was a bit duct taped. And since then it's gotten a lot more up to snuff. But I do think there is a lot of value in sort of like making the process manual at first to prove whether it's gonna work or not and whether it's viable.

And just for the record, we have a lot of improvement in our backend processes. Yeah, as every company does.

Every company always does. So we have only a couple minutes left. Left. One of the things we wanted to talk about was just making sure we gave really clear takeaways from this content, because you're probably attending a number of sessions today. It could easily be in one ear, out the other. So I'm going to have each of us give a very clear, like, here is what I hope you take away from this, from listening to this talk. Neil, how about you go first?

Yeah, I think the most important thing when you think about an ecosystem, in my view, is organizational alignment and measurement.

Yes.

So you have got to be crystal clear, and that has got to come from the leadership team of the company, because it's not cheap to build an ecosystem. But, but identify the, the why is it important for your business to build an ecosystem. Make sure you have intentional and visible metrics that you can actually measure success, and make sure that's aligned to your engineering and product teams. And your go-to-market teams. It sounds simple, but from experience, if you don't do that at the get-go, you're always gonna be fighting for resources and justifying what might happen in the future.

[Speaker] Cool. I mean, mine is developers first, right? Your APIs are first-class citizen. It should be as important to have your APIs be world-class as the rest of your product. It shouldn't even be a conversation, and if that isn't the mentality of your engineering team, It's difficult. I mean, you want— that's how developers have a lot of different places they can go today to build a business, to integrate with. And the easier and better experience and more value you're providing developers, the more likely they're gonna give your attention.

And mine is going to be a little intense sounding, especially while I was in venture. I met with a lot of younger and older companies that were saying, we're a platform, we're a platform, we're really focused on building the ecosystem, and I think that that's awesome and we should all strive to build that, but being a true platform's hard. Like, you really have to find product market fit. So most companies aren't platforms. Not everyone can be the center of the wheel. Many of us are actually spokes, and that's a good place to be. So if you wanna figure out whether you have a real viable platform opportunity, do a little bit of the upfront work to find product market fit for it first. That's, for Slack, building those first 80 integrations ourselves seeing the demand for the platform come out of that. So build that product market fit to start. I think that would be— we'd be ending with 1 minute to spare, but I also don't want to get sung off the stage. Does that sound okay?

Sounds great.

Great. Thank you all.

Thank you very much.