Scaling Revenue via Indirect Channels and Platform Ecosystems

Panel (moderated by Cece Stahlsmith) with Vicki Lynn (Stripe), Neil Wall (Box) and Cece (Slack) about building and scaling platform ecosystems. Key practical themes: start developer-first (APIs and low friction onboarding), prove product-market-fit before claiming platform status (build early integrations in-house), and instrument a platform funnel (partners → engaged builders → published integrations → customer discovery → active adoption). Concrete data points cited in the session: Stripe reports “a couple thousand partners” in its ecosystem; Box has ~1,400 ISV/embedded partners and reports just over 40% of new ARR coming indirectly via partners; Slack lists over 1,500 apps in its directory and said 90% of paying customers use apps in a given week. Measurement advice included IWOW (integration weekly active users), ARR and average seat price comparisons for channel vs direct, renewal/upsell signals, and building dashboards for the platform funnel. Pitfalls: avoid lock-in naming/tiers that remove optionality, don’t assume success (or…plan for scale), and prefer manual processes early to test demand before investing in backend tooling.
Questions this video answers
"a couple thousand partners" (as stated by Vicki Lynn).
About 1,400 companies (ISVs/embedded partners).
Just over 40% of new ARR (as stated by Neil Wall).
Over 1,500 apps (as stated by Cece Stahlsmith).
90% of paying customers (as stated by Cece Stahlsmith).
Chapters
Hello, everyone. How's Saster 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 going to need you to clap in response to my questions.
So, you know, we've got a big bet riding on this.
We have a big bet riding on this.
There's a free cup of coffee in the green room riding on this bed.
So, 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.
Yeah, 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've 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. 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. So, Vicki, if you could give us your intro.
Great. Thank you, Cece. So, I'm Vicki Lynn. I have been at Stripe for about four 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. 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 six 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 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 1400 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 three and a half years. So I got to join before we launched our platform, launch it and scale it from there. We have over 1500 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 you 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 Saster. How do I think about whether or not I have the opportunity to build a platform or an ecosystem? So you 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 Vicky, 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 a completely unnatural decision to really focus on our ecosystem. A couple 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. 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 to get their work done. So we always had this kind of weird dynamic with freemium where we would just give away 50 gig for free. If you remember that sushi, I still have that shut down recently, but we learned that that's kind of expensive. You want to be relevant to a certain point, and once you have a minimum viable relevancy, if you will, then you gotta 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. On the other half, you have partners and ideally developers and 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 ad 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 like 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 or 2014 growth was due in part to integrations. So because we were seeing slow, 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 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 want to speak to that?
Yeah, I mean, that's because I think earlier stage companies are always, well, every company is resource constrained, 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, 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 second slide here, which is how do you measure whether or not an Ecosystem is actually paying off for your business. So I think that that's the number one thing as I'm sort of referring to as Slack. We just had so much many customers using these integrations and saying they're really valuable to them. We knew that it was making our products 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 like a compelling business problem that is existential to your company. And the an ecosystem just happens to be the most effective tool never to do that. For Stripe, again, our core product is an API. You cannot use our product unless you code. But of course there's millions of businesses out there that want to accept payments online. And so it was a natural extension for us 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 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 and running. And so that's the problem we solved. And that makes measuring value easier because you've already identified value, 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 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 do it in two ways. One is on the differentiate dimension. We measure IWOWs, 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 while 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. 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. 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 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 gonna 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 gonna 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 gonna 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 is the next step. And then the bottom half of the funnel is where customers actually discover and then active 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 CC 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. But even the early days from a qualitative standpoint, you will have 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, you know, 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, especially 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. I think actually at Box you had to cut losses here and think about where to focus the 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 there's really 2030 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. So that would be a kind of best practice here is just make sure that you don't deviate your APIs irrespective of the type of partner. But yeah, we struggle with this candidly because the 1399th 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 I mentioned we have over 1500 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 for us to succeed, the value of everything built on our platform in sum should be greater than than the value of Slack by itself. That to me is 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, 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 up market 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 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, 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 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 going to 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 love providing that opportunity and it's something I'm really excited about still for the future of our platform in particular. And you can look at companies like Guru and Workday, Not Workday, Work Ramp, if you've heard of Work Ramp and Troops. They're all companies that have grown up with us as a slack platform company and I think they have really exciting futures. So one thing it'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 trapdoors or things to avoid when you're building a platform?
Yeah, I mean, really the main 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 these are very tactical things. We rolled out our first official partner program over the summer and one of the hardest decisions actually was naming. Like, what do you name a partner who's in the program? And so we were conservative, I think. And what we did not do is we did not put in like a gold. You were 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 two years from now when you want to add another? Like, add another tier, like better than gold. Platinum. Platinum, better than gold. So we wrote for naming, we sort of said, okay, the first thing we're going to go out with is you are a verified partner. Verified. It's not the flashiest thing for sure. And from a marketing perspective, it doesn't kind of inspire the hordes to sign up to be a verified partner. But it's descriptive, it's accurate, and it gives us future optionality as we want to layer in benefits, layer in like higher requirements that we can kind of 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. That is lots of people would start using the product but that actually would have been difficult 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 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 were 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 you're every company here, you'll 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 going to 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 entire partner experience. So partners would give us their information through a type 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.
But was that if you were the contracts the same with each partner and just the processes by which you manage those different or was it actually you were just trying to lots of different things iteratively with each of the types of partners on the contract or the business model construct itself?
Yeah, the core relationship with partners was the same. It just we didn't invest a lot in the back end tooling and the processes to scale because we weren't quite sure like how many partners are going to want to be on our partner gallery. Are customers going to find value in that partner gallery? You don't want to spend six months building out entire partner backend infrastructure if you don't know for sure that this is the thing that is going to be successful. 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 like you can't get resources to make it better because it's just like is it high enough priority? Like we should probably ship this other feature above it. Like it always slips that happen to get it again it box. 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 going to work or not and whether it's viable.
And just for the record, we have a lot of improvement in our back end processes. Yeah. As every company does.
Every company always does. So we have only a couple minutes 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 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 view is organizational alignment and measurement. So you've 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 identify 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 you're going to market teams. It sounds simple, but from experience if you don't do that at the get go, you're always going to be fighting for resources and justifying what might happen in the future.
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 going to give your attention.
Cool. 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 is 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 want to 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 and see seeing the demand for the platform come out of that. So build that product market fit. To start, I think that we'd be ending with one minute to spare, but I also don't want to get sung off the stage. Does that sound okay?
Sounds great.
Thank you very much.










