Ep. #12, Platform Success with Ceci Stallsmith and Paige Paquette of Calyx Consulting

Patrick Woods: Awesome, Paige and Ceci.

Thanks so much for coming on the show today.

Very excited to have this conversation with the both of you.

To kick us off, would you mind sharing a little bit about who you are and what you're working on?

Paige Paquette: Great, yeah, happy to be here.

My name is Paige Paquette, and I am a developer and Platform Marketing Consultant.

And previous to doing consulting, I was leading platform marketing at Slack.

I joined Slack way back in 2016 to head up the Developer Marketing team, which at the time wasn't really a thing, it didn't exist.

And over the few years that we did that, we grew the ecosystem to well over half-a-million daily active developers.

And it was a really amazing time.

Before that, I was Head of Marketing and a founding team member at a company called ZenHub, which is a productivity suite for developers that integrates really tightly into the GitHub ecosystem.

So have been thinking about developers pretty much for my whole career and it's a really interesting space.

Ceci Stallsmith: Cool, and yeah, I'm Ceci Stallsmith.

I have also been doing sort of platform and developer work my whole career.

I started at Box where I was an early member of the platform team, did DevRel, did product, went to a venture firm called Bessemer, where I actually invested in developer products.

In my time there, I got to invest in NPM and readme.io.

And then I went to Slack as the first platform marketer, and got to grow and build that team and function out as a whole, which was super-fun.

So that included basically launching the platform within three months of starting.

And then hired on Paige to take on developer marketing, building out the partner marketing function, which was like bringing the large partners to market, like Google, Atlassian and Salesforce.

And then, finally, I made it a big focus to have product marketing that was customer-facing within the Platform Marketing team.

Because, when you're building out an ecosystem like Slack's, if you don't have customers actively aware of and adopting the partner and developer apps and integrations that are being built, your ecosystem is not going to succeed over time.

One of the things that I was really proud of in our time at Slack is that we saw a really strong customer adoption of the apps and integrations that our developers and partners built, and that made the overall platform successful as a whole.

And so Paige and I left, and we are now consulting, because we found that there is just a ton of people who are building companies, and are trying to figure out, you know, we have APIs, we want people to build with them.

Are we a full-on platform play? Should we be thinking about ourselves as a platform and building out a platform go-to-market strategy?

Or should we be thinking of ourselves as like a product play with an API suite, where we're going to have a couple of strategic partnerships that are going to add a lot of value to our company?

So we work with the likes of Niantic and Twitter, and a bunch of other companies that we can't list, to help them build their developer platforms.

Patrick: Incredible, thanks for the background there.

So to kick us off, I think to pick up where Ceci left off there, you know, we have a lot of founders in our audience, a lot of early-stage companies, and they're going through this sort of framework of asking these questions you just teed up.

Should they be product-centric or platform-centric?

What tactical advice would you give folks and early-stage companies, as well, as they assess and decide whether or not they should implement a platform strategy or not?

Ceci: Yeah, so I think the question is like, what is a platform strategy overall?

And depending on what your product is, that answer varies.

So if you're a founder building a developer tool, obviously, you should be pursuing the heck out of developers because they are your core audience.

I don't know if I would call that necessarily a platform play.

And I think the word that tool or utility can seem undermining and seem like it's small, but I think we all agree that products like Stripe and Twilio are extremely powerful and amazing companies.

And I would say that they are like utility APIs.

They're adding core functionality to the products that their users are building.

So that is one kind of sort of like quote, unquote, platform play or API-based business.

And then the next kind that I think about is essentially building what I call a two-sided marketplace, where you have a product and that product has users.

Slack is a great example of this. Slack has a messaging product. That messaging product has a lot of users. And developers build on top of Slack to add value to Slack the product. And as the value of Slack, the product, increases, Slack acquires more customers and developers, in turn, acquire customers with them.

That kind of platform is harder to figure out, like whether you have a viable model for it.

A lot of people are kind of averse to building their first set of apps and integrations because they're like, oh, if I'm a platform, everyone else should build to me.

That's wrong, in my opinion. Slack built the first 50 apps by hand themselves, and we had a whole team doing that full-time.

If you want to know whether you have product market fit or platform market fit, wink, wink, then build the first set of integrations.

And if they are well-adopted by your customers, then you got platform market bit and you can start thinking about opening up your platform for developers and partners to build to you.

Patrick: So you've described the sort of platform ecosystem as a flywheel.

And one question I had was, what is step zero for getting that flywheel spinning, but it sounds like you just answered that question for me preemptively, and it sounds like building those first set of apps is really the great way to get the flywheel spinning.

Paige: Yeah, and I would add to that as well and echo what Ceci said.

And just to sort of underline it, it's like with this type of platform, the platform that we're talking about where you are adding value to a core service, it really does come down to usage.

So people will ask what are the tactics to get developers to be interested in your platform?

And it's like, there's a lot of things you can do to seed interest, but people have limited time and a lot of competing priorities.

And so to Ceci's point, if people are building stuff that's not getting used, and if you're not making it a priority to drive adoption of the apps and utilities that developers build on your platform, they're not going to come back.

They're going to churn. They're going to go to the next platform.

Because, ultimately, usage is the number one key, I think, for continuing to drive a healthy flywheel.

Patrick: What would you say is the role of community and developing a healthy platform ecosystem?

Paige: I mean, community is huge.

And I want to just back up and ask, so what are we talking about when we say community?

Because communities can emerge organically without any sort of formal scaffolding, right?

And so to bring it back to Slack, just because this is the most recent example, we had a developer community in that people were building Slack apps, almost like from the moment that they could, right?

Simple Web hooks and then more advanced UI as that functionality was added.

And they were talking about it online at places like Stack Overflow and Reddit.

And so there was certainly a community.

But eventually, we decided to launch a formal community, which was a set of programs, both in-person meet ups and online component, to essentially formalize the community that already existed.

And I would really encourage people if not to build their own community, to think about where the existing community lives and hangs out.

In many cases, there are existing communities that exist, whether they're Slack groups or online forums.

And it can be really great when you're starting out to think about how to partner with those communities to reach into these audiences.

I think community is so vital for any product, but particularly developer products, because word-of-mouth is so key.

And community is one way to foster that word-of-mouth, right?

It always comes back to showing and not telling the value is something we talk about a lot as product marketers.

And community is sort of like the strongest way that you can show the value rather than tell, because you're just going to see those organic connections pop up with people in the community sharing ideas, sharing solutions, showing off what they've built.

And this is all sort of better marketing than you could ever possibly do as a company.

Ceci: I agree with all that.

I think I'm a little bit skeptical of the word platform sometimes, especially 'cause of my days in venture capital, when every small startup I met with was saying, we're going to be the platform.

And I'd be like, are you? I hope you will, but not everyone can be.

I think we also have a challenge right now with the word community.

I think community is really, really hot right now.

Everyone's excited about having the next community, and I think investors look at communities as these significant moats for businesses, especially B2B businesses.

And the problem is developers and just humans have limited time, and we all can't be in all of the communities, period.

That's just a fact. So when you're assessing whether community is a really good strategy for your team, here are a couple of things that I like to think about.

One, do you need to go try and build the community from scratch and host it on all of your own forums, et cetera?

Or are there preexisting communities that you can actually piggyback initially?

And basically again, like search for, I'm going to overuse this, like community market.

But do you actually have a community that wants to hang out together and talk about your stuff?

Or let's say like in the sort of low-code, no-code space, are these people hanging out in the trailblazer Salesforce community, and should you go send some really great DevRel and create some strategies to go work into the Salesforce community for the next two years?

And then maybe your own community is going to really grow and thrive.

And doing what I just described will actually grow your business even more than just trying to make everyone come to your hub instead of going to other hubs.

So I'd say figure out if you want to build your own or go to others.

And then, two, I love what Paige said about, you don't necessarily have to set the whole car up to have community driving.

People know how to hang out together on the internet.

This is especially something that developers know how to do.

So a lot of the success we saw in our community at Slack, we didn't do a lot of work for.

We kind of had some DevRels and I was in it, too, and Paige was in it, too.

We'd be like lurk at our community for awhile.

And then once we got to a certain level of scale, and also once the company was sort of big enough that we had to really be concerned about this, then we added some more scaffolding around what we were providing the community and how we were interacting with them more formally.

But we sort of let it grow up organically.

And I think you can feel when a community's organic versus when it's not.

And so those tools, again, like, let people have a Slack team together, it's called a workspace now, but I miss those days when we called it team.

Online forums are also great. You could literally just use Airtable to create an online forum for you.

A good example of this is Airtable's own online forums.

Check theirs out if you want like a really basic version of pre-seeded community.

I should have a third example, but I only have two. So one, two.

Patrick: So thinking from a developer standpoint, you know developers are busy folks.

There's high opportunity cost of adopting new tools and technologies for them.

What are the characteristics of platforms that have driven developer adoption over the long-term?

What do you think the things that, what are they looking for as they're assessing whether or not to spend the time with the docs and building a starter app, for example?

Ceci: Yeah, I have, I mean, if y'all had seen, I did a talk at Heavybit a long time ago and I have sort of a formula for this.

Because when you're product marketing a platform, you need to be communicating the value of that platform.

So the way that I think about it is there's three things that, really, it's kind of two, but I broke it into three, there's three things that a developer might want or find valuable from you.

And that is really useful technology that is adding to their product significantly.

Again, Stripe, like I need to charge my users when they're trying to check out, that's extremely useful.

And the reason why Stripe is arguably the best at it, it's the best product, the fastest to integrate, the fastest to set up.

Two, I can make a lot of money using this product.

So if you have a way for developers to get rich, there's going to lots of interest.

And then, three, I can acquire lots of users by using this product or by building on this platform.

And two and three, in my opinion, are kind of the same.

Usually it's going to be I can acquire users for this product and that will allow me to grow revenue over time.

So that's how I think about it.

If you are building a two-sided marketplace sort of platform that we were describing, is what Slack offers, you really, again, like we were saying, need to focus on how are you making sure that at least some of your apps are seeing successful adoption from customers.

And then if you're seeing a ton of success with that adoption, the next thing you think about is, are we going to start letting our users purchase these products through our platform?

And are we going to set up a revshare for products?

And this is, I see a lot of especially B2B companies feel hesitant on figuring that out.

That is a challenge. Slack does not let people charge for apps through Slack's platform. It's a huge can of worms.

And if you read the news recently, you've seen how Epic is suing Apple for taking a cut of all in-product purchasing or in-app purchasing.

And I mean, if we all think about it, of course Apple's taking a cut for all in-app purchases.

That's how their platform is really viable and it's so successful.

On the flip side when you're Epic, you say, hey, I'm driving so much value to your product, the iPhone or iOS, you should let me have more of the revenue that I'm making through your product with in-app purchases.

So the revshare piece is really interesting and honestly something that Paige and I haven't had to work on directly.

And I think we're looking to learn more about that as we are working with a bunch of different platform companies in parallel.

Paige: Yeah, and I would add, Ceci, tier three pillars, I would actually add a fourth pillar.

It's just my plug not to sleep on this, which is the other value of platform can be customers integrating with it for their own use cases, right?

Which is actually a huge opportunity.

It doesn't have to do with the revshare angle or the challenges, but also the benefits of this public platform that Ceci was talking about, where you need to sort of make some apps successful and make sure that people know about them.

There's also a value of just letting your customers customize the product for yourself. So for Slack, this was companies, customers building custom apps that were private for their own companies. There's all sorts of reasons why a customer might want to not use a public app and instead build something that is custom to their own needs, to their own security requirements as specifically built for their own use case.

And certainly, developers, like we all know, they love to have things be just so for their own workflow, right?

And that can actually be a huge driver of usage.

And I think something that is less thought about and less talked about within companies is that internal opportunity, which is internal developers.

Not third party developers trying to make money but just customers who are trying to get more out of your product.

Ceci: I will-- Like, a strong plus on that.

I think that, yeah, that is something we haven't talked about as publicly and is so big.

If you look at the public number is 600,000, is it daily actives for Slack's developer ecosystem?

That number is actually higher. We just haven't released public numbers in awhile.

A vast majority of those are customer developers who are building a custom app for their needs.

And I think the other piece that you're going to get here, a great example of a company that has killed it with that model is Salesforce.

And I think Salesforce might be sort of one of the best examples of one of the original B2B platforms, other than Microsoft in terms of success in the long-term.

And you see every single kind of product on them.

You see the big partners, you see companies that grew up on them and went public, like Viva.

And then you see a ton of these internal developers, or I don't really think they're called developers.

They're like Salesforce Operations Specialists who customize Salesforce for their own company's needs.

The thing that you really get out of that is way reduced churn.

Because when a company has a full-time person worrying about the implementation of your software, it's really hard to rip that software out, 'cause that's that person's job, and they're going to defend their jobs with everything.

So if any other product comes in and says, hey, we're faster, we're easier, you don't even need a full-time person to service us.

Guess who's going to be really threatened by that?

The person whose full-time job it is to implement that product.

And then second, on top of that, when you've customized a product in every single way, ripping it out is really hard.

Because an out-of-the-box product is not going to do everything that the customized product does.

So we talk with a lot of earlier-stage companies sort of on like an advisory basis.

And there's often this question of like, when do I do all this platform work?

And like, I have APIs but they're not open.

If you are documenting your APIs well and haven't fully opened them up, you should consider actually opening up your APIs for your customers alone.

Because it's going to make a really big difference for your sort of long-term success with your customers for both expansion and reducing churn.

Patrick: Yeah, strong plus one from the Orbit team on that.

We actually opened our API from essentially day one.

All of our early customers are very technical, and so we've seen the learnings that come from that and what people are doing, where they're going, how they're building Orbit into their workflows.

I feel very positive about our choices now based on the guidance from two strategic thinkers like yourselves.

Paige: That's awesome.

Patrick: So I'm curious what is the most common reason a platform strategy or rollout would fail?

Paige: I have a couple of quick thoughts.

And it depends on the type of platform, is going back to the beginning of like what is platform?

It can mean so many things. But I think a couple things are, one, like you're not really going to drive usage.

So you're thinking a lot about let's send swag to developers, and then but you don't have the usage to back it up.

Meaning it's hard for people to discover and adopt what developers are building. I think that's one thing.

I think another thing is developer trust and not thinking enough about what you need to do to build the trust and then to keep it, meaning things like asking developers to build in one way and then changing something and asking them to rebuild or to change something significantly.

These small cuts can really add up and it's really hard to regain developer trust, because there's just so much competition.

There's so much competition for people's time and intention.

And so it's really, really critical to think about putting practices in place in your company.

Because once developers are building on your product, something that you may not think could impact them, i.e., like a UI change that somehow in some circuitous way impacts what a developer has built, you might not kind of realize that, that might not even be part of your platform team, but that can really erode trust very quickly.

Because all of a sudden it's like, hey, I built this thing on your platform and now it looks different, and it's behaving differently because of what you did.

And so it's just these easy mistakes that can be really, really hard to walk back from.

Ceci: I so agree on the developer trust piece.

And I think we all, the flywheel concept for a two-sided marketplace platform where you're trying to help developers acquire your customers and help them acquire customers for you, for that one, if you don't have the usage, you're not going to succeed long-term.

It can take a little while to fail on that front.

Like, you can kind of string it along with marketing gives and with money.

That said, the developer trust piece is essential. Here's the hard thing.

If you're building a platform like we're describing this two-sided one where you're helping developers acquire users, there is going to be inherent cannibalization of your ecosystem at different stages of growth.

That is actually inevitable. Like, look at Twitter. You know, we work with them and they are a fascinating platform.

They probably have one of the most notorious developer screwups.

They also still have plenty of developers who build on their platform, they messed up the trust thing.

So how could they have done that better?

I think one of the areas you see challenge come up the most is going to be out of your product team.

I think marketers, like the danger with marketing is marketers could promise the moon, and then you never deliver it.

But if the product's there, a marketer can be horrible or a marketer can be great and it doesn't matter; if the product's there and the developer can use it, fantastic.

If your product team does not have a clear strategy and a plan for awhile for your ecosystem, it's going to be really hard to establish developer trust effectively.

Because developers are building with you for the long haul.

This is not a casual little thing when you are either building a product on top of another product or using an API to be a foundational part of your functionality. It's a commitment. Trust is required. So your internal product team needs to have a good sense of their audience, a good sense of why they're building, and you probably have to have thought through all the ways where you're going to go step on your developer's toes, and essentially vestige those early.

I think it's okay to say, "In a couple of years, we're probably going to go do this thing that you're doing."

Like the Flashlight app on iOS. That's a good example where, when they added Flashlight to the core functionality of the OS, everyone was like, oh, they're killing the Flashlight apps.

And it's like, yeah, that happens. It sucks, but it's just the Flashlight apps and everyone still builds on iOS.

No one's like, oh, no, they're going to get me, I have a Flashlight app.

So I think that you have to see cannibalization is part of it.

Given it's part of it, you have to have really good plans around what you're going to build with your product, and then dev rel and marketing that can communicate those plans effectively to your ecosystem, so that people aren't super-blindsided when you make changes.

Paige: Yeah, I think that's a really good point.

Back in 2016, I think Slack might have been the first major company to roll out the public roadmap.

And that was before my time, Ceci. I think that was maybe something that you did.

And developers would always come to us and be like, it's so amazing that you share your roadmap.

Like, wow, nobody does that. And now it's become a little bit more standard.

But that's a function of building trust, right?

It's like, here's what's coming and we're going to try our best, things will change.

We'll try our best to communicate it.

And there are other sort of, I don't want to say cheap, but, you know, quote, unquote, cheap ways that you can start to build trust.

So in the early days, when people are building on your platform, they rightly feel like they should have special access.

And that is very fair. Because they are spending time developing on your platform, and presumably, even driving more awareness of your main product.

And oftentimes they're also evangelizing the main product and even writing about it.

And so it's totally natural for them to feel entitled, and I mean that in a positive way, to access.

And so it's like, just give them the access.

And by that, I mean do things like make sure that they're involved in things like early betas and opportunities for feedback on upcoming changes, even changes, like I said earlier, like UI that you might not immediately think of as a developer-pacing change, could impact their product.

It's things like just making them feel special, doing things like advisory boards, which is a fancy-sounding name but really just means gathering some developers in a room together every quarter and allowing them to sort of meet your executives and hear early product ideas from your PMs.

So it's also a fantastic opportunity for early feedback, but it also serves to just strengthen that trust, right, develop those relationships.

And this isn't necessarily scalable to hundreds of thousands of people, but there are just ways that you can do this early to build that foundation of trust so that when, inevitably, you will do something that might cannibalize part of your platform.

But hopefully, if that happens, you've sort of put the communication in place that it's not handled publicly.

Patrick: So one question I ask every guest is, what's the secret to building things developers love?

If I had to guess what your answer would be, I would say it's building developer trust.

Would you agree with that or is there more to add?

Ceci: I think you can't have a crappy API. So you need a good API.

If your API is not unified and doesn't make sense, and is horrible to get through and really poorly documented, that is inherently not trustworthy.

So, trust comes after that. But I think if you get that in place, then building developer trust, yes.

Paige: I would say that there is no secret.

The secret is, start by understanding your audience and then building something that they want.

And oftentimes you can't, I would say you can't do that period without doing a lot of research and talking to your developers, and actually sitting down and making time to have conversations with them, and figuring out what their pain points are and how you can solve them.

Ceci: Yeah, big believers of doing unscalable things in order to scale.

Patrick: So I'm curious, we've talked a lot today about platforms and developers, and go-to-markets and things like that.

I'm curious, what keeps the two of you coming back to this space and to this problem, and to leave your jobs doing it, to form a new business focused completely on this set of challenges?

Ceci: I like to describe it as I'm this weird platform nerd.

It was the first full-time job I had and I think I just kind of fell in love with it.

But when I really think about it, I think the reason I like this space so much is because there are so many audiences you have to deal with and that makes the work interesting.

I think I'd get really bored if I was product marketing or selling or building product for sort of one type of buyer all the time, my whole career.

When you're dealing with an ecosystem, quote, unquote, you have long tail developers, tinkerers, hobbyists, you have these really large partners who come from big companies that have big egos, and have a ton of skin in the game and are going to be sort of hard to negotiate and deal with.

And then you have your core customers, and your core customers have a huge suite of needs.

So having so many audiences, especially as a marketer, is fascinating.

It keeps the job fresh and interesting all the time, 'cause you're always having to sort of switch your empathy to a new user.

So I like the big set of audiences you have to deal with.

And I think the other thing is when you really unlock a successful platform play, it causes wildfire growth. It's so cool.

And it also opens up the opportunity, when I was in venture, you know, I met with lots of different companies, and you say no to 98, 99% of them.

But what's cool with a platform when it's a successful one is the answer is pretty much yes.

Unless you're doing something malicious, yes, you can build on our platform.

And it's pretty much up to you, the founder, the developer, whoever you are, to be successful.

I'm going to give you as many tools as I can.

It's a yes, like, I will give you all the access and marketing tools, and access to our customers as possible to help you succeed.

And if you can build a product that people are going to love, you're going to rock.

And you can really build something on top of this.

So I really loved switching from an industry where the answer was mostly no to an industry where it's yes.

And if you can build something that finds product market fit, you're going to rock.

Paige: Yeah, I think I just really like developers. I just like developers. So I come up through product marketing, so that's my bias.

Developers have such a low BS tolerance for lazy marketing and lazy strategy. And I think, increasingly, that's just people in general. It's not just developers, right? Developers might be more opinionated about it on the internet, but certainly, most of us can tell when something's just lazy, it sounds inhuman, it sounds like you don't really understand me. You're not being a good host, you're not respecting my time. That's my ethos for my work.

And I think that developers are just fun.

Like, it's an audience that you can be human with and talk directly with.

And I also think it's really fun because there's so much demand for platform and developer efforts.

Comparatively, it's a very small new group of us, right?

And we all sort of know each other. And so it's fun because we're all sort of figuring this out.

As you know, Patrick, you're one of the people figuring it out as we go along, like, what does success look?

How do we measure success? What are the best practices? What are the industry benchmarks?

Where in other adjacent industries might already be defined, we get to be the ones who are defining them, which is really fun.

Patrick: Well, you've both been very generous with your time today.

If people wanted to learn more about what you're working on, where would you send them?

Ceci: Well, we have a website. It's Calyx, C-a-l-y-x, dot consulting.

But also just find us on Twitter. Hopefully, we can somehow link that in the description.

Paige: My handle is @Paigepaquette, just my name. Not super-creative with that one.

Ceci: And I'm @CeciStalls, but Ceci is C-e-c-i, which is inherently confusing. So, see you on Twitter.

Patrick: Awesome, thank you so much.

Paige: Thank you, this was really fun.

Ceci: Thank you, Patrick.