September 6, 2018
3 DevRel Approaches to Product, Support, and Security
In this post, learn how folks in our community leverage developer relations to have a major impact on their companies.
Thank you so much for joining tonight. I'm excited to talk about this. My name is Ceci, and I really love platforms. I never expected I would ever be saying that in my entire life.
I grew up on the East Coast. I thought I was going to be a teacher. I went to Stanford and I majored in english and psychology. Got to the end of that, and I really still thought I was going to be a teacher. And then I took a course. Being a teacher is awesome; I want to do it someday, still.
I took a course where I saw Aaron Levie, the CEO of Box, speak. Do you follow him on Twitter? Do you know Aaron? He's like the funniest human in the world. Me speaking right now, it dwarfs in comparison to Aaron speaking. He's like a bright, shining light. When he's around you, you're just like, "I want to do whatever you're doing!"
I saw Aaron speak, and I just emailed him. I was just like, "I need to work for you!" And somehow that got me to Box, which was really fantastic. I got to be a founding member of the platform team there, with that guy right there, named Joel. And learned a lot from him.
I actually started in developer relations despite having no technical background, which was super duper fun. I fell in love with platforms in my first job. I got to help grow a bunch of the ecosystem at Box, run some programs, did a little teeny bit of product and then went into venture capital for a year. That was my time in the dark side.
While I was there, I invested in npm. You guys know npm? Node Package Manager, yay, woo-hoo, good things! Nice People Matter... It doesn't actually stand for anything. Did that for a year, looked at a bunch of dev companies, then went to Slack where I run platform marketing.
I'm really here to talk about growing platforms in the go-to-market sense, but it's a very specific kind of platform. I am not speaking of growing a platform like Stripe or Twilio. Those are platforms where their APIs are very, very useful technical building blocks for products. I'm talking about building platforms where the platform is actually a core product that has users on it.
You build on top of the platform as a developer to meet those users' needs. Inherent in the platforms that I'm going to be talking about is a core product with users that are separate from the actual platform play. It's not only for the technical purposes that you'd be using these dev tools.
I've been spending my last two weeks thinking about the Platform Virtuous Cycle. This is a very high-level look at why companies like Salesforce, Facebook and Slack build platforms. We'll just walk through the virtuous cycle really quickly, because a ton of this talk has to do with it.
They have a product. You have a product. The product has users. Those users are really happy, and they're growing. The developers say, "Hey, there's a ton of potential and a ton of users on your product. We want to build to meet those users' needs where you're not going to meet them outside of your core product."
Those developers succeed and make your customers really happy because they're going to deliver things that you don't deliver. So, for instance, on a Slack, or on a Facebook, this is like Zynga. Facebook's not building tons of games. Zynga is building tons of games. Consumer platforms sometimes tend to care about where ad revenue comes from and that becomes problematic. But not the same for enterprise platforms, usually.
Happy customers recommend your product. You develop these really, really wonderful moats in your product when you have all the apps, all of the tools that people really want to use for work in their workday. In Slack, for instance.
For Salesforce, the salesperson never has to leave Salesforce all day long, because every single product they could ever want to use outside of Salesforce is integrated into it. So the inherent value of platforms, the Virtuous Cycle of a platform.
We'll walk through these four things today: how to identify and tell the story, how to acquire developers and partners, how to equip developers and partners and how to tell the story again.
Once you have people being successful on your platform, the next best thing to do to get more people on your platform is simply to tell that story again.
Step one, identify your audience. Determine your value as a platform, which can really vary depending on who you are and what you're doing. And then, three, write the narrative. This is sort of product marketing 101. I don't know how many people in the room even have a product marketer or are starting their companies and don't have a product marketer yet. If you don't have one, hopefully this will be useful.
I'm going to give some tips that are high level and some that are extremely low level about how to build a product marketing brief. So, hopefully that will be useful for anyone who's starting a company.
You need to know your audience when you're telling the story. In order to know the audience in this Platform Virtuous Cycle, there are two sides. And that's what I really like about my job. Unlike someone who does product marketing for a core product that just has customers, when you do platform product marketing, you have customers, and you have developers.
Those customers and developers, when you're in enterprise, specifically, often split into two personas. So that's long-tail developers and then partners. So, for instance, the way that Slack talks to Microsoft or tries to get Microsoft to work with them, or us, is very, very different from the way that we get our long-tail developers to work with us.
There's a super different narrative we have to tell. On the other half of that, there's end users and team admins for enterprise stuff. Team admins are very scared of deploying apps to their users, but they also want to. So the story that you tell, an end user of your product about why integrations are really cool and really useful for them, is super different from the story you tell a team admin to deploy apps into their accounts.
The first things is a platform v0. This is just one suggestion I would make based on the companies I've worked at previously, before you actually go ahead and try to open up your platform to a ton of developers, to get them to build on it. I would actually suggest seeding this yourself.
Many companies actually already do this. For instance, Slack did this from super early on. The first 70 integrations built on Slack were built by Slack. And in terms of why people actually thought Slack succeeded in its first year and half of existence, a lot people thought that was because of integrations and because of their platform strategy. When really, Slack had just seeded that themselves.
They proved, super early on, that customers were happy when there were integrations on the product. They initially proved that the platform was inherently valuable. Box also did this; the first integrations on top of Box were built by Box. So the developer wasn't part of the story. The company itself actually just wrote it themselves. That's telling the story to the customer that integrations make my work simpler, more pleasant, more productive.
The product marketing that we used was that image I showed you. And that was actually in Slack's first call deck. It's still on the website to unify all the tools and services used for work. That's still the customer-facing platform narrative. And that's something that has been defined and has been in every single piece of product marketing we do about the platforms to customers.
Step two is to then extend your platform to developers. Once you've proven that there is inherent value for your customers to build on your platform, you have to go ahead and open it up to developers. And this is where the narrative gets really, really fun, in my opinion, and this is the kind of marketing that I super enjoy doing.
The question there is, what do developers want to hear about your platform? It varies in terms of platform. The way that we did it at Slack was to actually say that the value here is to build amazing products for people at work. So what we're trying to communicate is that you will achieve adoption and you will achieve building a really cool product on top of Slack with that value prop.
The narrative, what we tell the market, what we say to developers, is "Join us on our mission! Our mission is to make people's working lives better. You can be enabled to join us on our mission." So it helps them see the potential for them to actually succeed, which is the third part of that cycle. This worked really well.
We launched our platform in December with all the dev-facing marketing. It was very effective. People got super excited. And so now the product marketing dilemma and the thing to think about in terms of telling a product marketing story to the world, and this is where I'll get really, really practical with advice, is to repeat, repeat, repeat.
You have to tell your narrative again and again and again for people to hear it.
We have really small attention spans. You have to reiterate your message again and again for people to actually know what it is. Slack says its mission a million times a day, and it's really effective. People know what Slack's mission is as a result.
The fun part about product marketing, in my opinion, is defining the narrative and then saying, "Okay, this is the narrative we're going to imbue into every single piece of product marketing, or marketing in general, that we're going to do for the next six months." And then knowing that there's going to be a different narrative that you adapt to in the six months after. Because you want your ecosystem to evolve with it.
Just some practical ways that we've done this at Slack recently, in Q1. This last quarter, this is very, very up to date. The next example I'll show you actually got launched today. So we're going to be very, very timely. In Q1 we had no products launching, so we were like, "How do we get loud in the market in Q1 if we don't have a product to launch?" We actually decided to show developers how much we were backing them by opening our product roadmap for the platform team, specifically.
Basically, the idea was, "Are developers coming to join us? Yes, they are, but how can we increase the number of people who feel assured to join us?" We did it by opening our product roadmap. And the messaging there, it was again echoing that messaging that I showed you that we decided on in December. It was, "Join us in building the future of work." Again, "Join us in the mission," that rallying cry.
Today we launched Sign in with Slack, which is what it sounds like. It's a way to sign in to any app you want using Slack. And this is the product marketing brief, so any time we release a product, we create a product marketing brief. So things that are useful to have if you're building this out within your own org.
Have the narrative written out, have the audiences written out, and then every time you launch a product, have a product marketing brief.
Building a good product spec is really, really obvious run of house. Building a product marketing brief shows you how to say this is what the narrative should be, that we're tying it to overall messaging, and then here's the core messaging for this product.
I literally screenshot the product brief, the product marketing brief that we used today that I built a couple months ago. And it shows the two different audiences and then the narrative overall that it fits into and how it's echoed in our dev-facing messaging. It's just very practical.
Simple takeaways here for telling the story: seed the platform value before rushing into it. It's really easy for everyone in the world to say "I have a platform," and for "platform" to become a totally meaningless word. It does seem like sometimes it's overused.
Two, have a single, living document that shows your narrative, your audience and your value props. It's just really useful for your whole company to level set, especially as you start to grow. It's something that's becoming increasingly important for us at Slack, because we just have so many people, and we need to make sure that everyone's on the same page about how we describe the value of the platform, how we describe what it's purpose is.
Finally, product marketing briefs. Really basic, but really useful. This is just something I really wanted to add in here. I think that every single platform play can be narrowed down into three value props: useful or cool technology that's cutting edge, ways to acquire users, or ways to get revenue. With Slack, ideally, we have all three.
You can build a bot. Bots are really cool, really cutting edge. Woo-hoo, bots. You can acquire users, that's definitely true. And someday we hope that you're going to make a lot of money on top of Slack. For a Twilio, it's really useful tech. You're not necessarily going to be acquiring users through it, but you're definitely finding it useful. I think, for almost any platform company or company building a platform play, one of these three value props is true. Or all of them, in an ideal world.
Okay, step two, acquiring partners and developers. We're going to go back into the Box days a bit, and I'll show you different examples. Ideally, you've acquired tons of customers or tons of developers just by putting your narrative out there. But in the real world, it's really hard to get people to actually build with your product. Marketing can be a really, really, really effective lever to do that.
Here's the first one: When you launch new products, get partners to build for them. There's nothing that people love more than free PR with you. And this helps if you're a bigger company or a company that people really like to write about. But if you get enough partners who are interested, you can often drive some decent press.
For example, this was our new Slash Commands that we launched at Slack, and we didn't have an integration with Lyft to date. But we got the Lyft team to work with us for the Slash Commands integration, so they were a private Beta partner. It drove them and a couple other partners to build with us. It was super great. It was a very easy way to acquire the partners, because we were delivering value to them, especially by doing press with them.
PR is a really good lever. This was awesome. We actually threw all of our developers' logos on a billboard when we were doing this mobile ecosystem called OneCloud. It's no longer a brand for Box, but it was a super effective lever in getting these partners to build for us, or build with us. It's expensive to do a billboard, but you can think of other ways to get partners to build with you for a launch event. That is a very, very effective way to drive to a stake-in-the-ground moment, when your app is going to be released and then they will get attention.
Part of the thing to think about is people build because you have useful technology, because you can help them acquire users, and because you can help them to acquire revenue.
But sometimes when you can't deliver on those things immediately, you can deliver on getting them some marketing. And it's not that hard to do.
And the last thing, this is actually an email from Joel, is to use events. I think that everyone knows that developer events are super duper effective. It's why we do so many developer meetups. It's why we do events like this at Heavybit. Events are a really good way to get your partners and developers in long tail excited about working with you.
The thing I would think about with events is there are a ton of different tiers to think of them at. This was a super small-scale, elite dinner with our CEO and a couple of thought leaders in the iOS space that we did during WWDC. You can also do things where you get everyone to build towards events like Dreamforce, for instance. You launch your apps with Dreamforce together, and everyone feels really good about it. Events are a very good, stake-in-the-ground way to influence your partner to be excited about working with you.
Two, this one is really, really helpful and it's something we actually haven't implemented yet at Slack. We're working on it with the DevRel team at present. It feels icky to treat your dev ecosystems at times like a sales ecosystem, or whatever you want to call that, like a sales funnel. But it's really, really effective, too, because you don't know if you're doing really well at marketing your platform if you can't track the impact that your marketing has.
Metrics-driven marketing is very, very important. It's really useful to actually just build out a developer funnel. This is the simplistic one. At Slack, to date, it's really hard to build ours because we don't actually require developers to register with us. It's really hard to track the top of the funnel. But when you do require them to register, get an API Key, you can track that. You can look at everything through a funnel lens. It's extremely effective.
I think the ways that you think about this are there are different kinds of marketing you do to get people to grow the top of the funnel and then move through the funnel. For the top of the funnel, it's content marketing and other, large-scale PR and events. But the middle of the funnel with building, it's doing a ton of education stuff. That's something that I'm trying to kick us into gear at Slack right now. To get people published, it's usually those launch events, or tutorials on how to publish your app and why it's effective, if it is effective, which is exciting.
Adoption is where you need to equip partners to actually effectively get to your customers, to get used. I'm just going to talk about how this applied to OneCloud. This has been fun. I went way back into some really old decks that we made, way back in the day.
What we did with OneCloud, this mobile ecosystem we had for Box, is that first 30 apps that we had there, Joel and I just straight up emailed a bunch of people who had iOS apps, and we were just like, "Hey, we're at Box. We really want you to work with us." And it was very hand-holdy, and it took a long time to get them to build, and we had to convince them of it. But it worked.
Then to get that next 300, it was still pretty hand-holdy, and it was pretty much us running partnerships out of the platform team. But by the next 200 that we added, when we went from 500 to 1000, we actually scaled the process. We implemented a CRM, we tracked all of our emails. We started doing lists of potential developers that we could work with and doing actual mail blasts to them to see who would respond. And then if they did respond, we'd take a call with them.
We actually scaled out the process the way that you would with a sales process. So literally we applied what you would do in sales to a platform, and it worked really well. We always made sure that we did get on the phone with people, or we gave them really, really good content to help them get equipped to build.
The last point about building a platform is that it's super important to be human and to have a face. That was something that our VP at Box was really emphatic about, and it's really interesting to think about now, as Slack's platform is scaling really fast.
It's critical to actually meet with people when you're trying to build an ecosystem, because a lot of an ecosystem runs on goodwill and human relationships.
So as you wouldn't try and sell to a customer without ever meeting them, though that is kind of the case today, it's really useful to actually meet your developers, know what they're about, take their pulse, and react to who they are as people. It helps to do events for this. Makes it much easier and scales it .
Practical applications: ID what your developer audience wants. If marketing is a lever you can pull, then it's a really effective lever. Build a funnel, track your developers. You won't know if your marketing is working if you don't track. Implement a CRM; if you're starting to really scale, it's really, really helpful. And think about how you improve the process. Talk to people.
Okay, so the next part is like, how to equip your partners and developers to be super effective. The first one, which I don't have an actual slide to go in depth on, is the most simple thing, but it goes so far. Your long tail can make a ton of noise for you if you equip it to do so.
If you have 100 apps that are not really huge names but you give them each a little instruction on a way to tweet on a day that you have a launch, and 50 of them do, suddenly that's a pretty big impact. So make sure that you don't neglect your long tail, and equip them to help you be loud in the market. It makes them feel included, and it makes other people pay attention to you. So it actually works as your own marketing.
Show people how to succeed with you. If you don't, you can often end up with really bad apps. Two ways that we've been practicing doing this at Slack, something that's coming up for us that we haven't even launched yet, is interactive messages. We have a private beta for interactive messages. Interactive messages means messages with buttons in them.
We're working on that with partners, and there's been a lot of discussion about these partners that we launch with. They're going to be looked at as the golden standard, or like the way that you build interactive messages. Sort of like when they launched iOS and then opened it up to developers. They didn't just launch, let anyone build on top of iOS. They made sure that the apps that were built on top of iOS were really, really, really great, because they would become the de facto standard for the developers that followed them.
This is not hard for your team to do internally, as long as you have a little bit of time. You just need to build a product marketing deck to show your partners in private beta. And then walk them through the best use cases and the messaging that you want to use for your future products. That's what we've been doing with interactive messages. It's going to be fun.
Show them how to build. Show them what's effective. This is just through education. It's very, very simple. This is actually not even written by us, so we've just taken stuff that our community is writing about, on how to build on Slack, and are sharing it through our channels, and it's getting tons of traction. This guy Ross is awesome, and now we're friends, so it's fun to take your ecosystem and make them feel really empowered to teach everyone else about how to do things well.
So you don't have to be the source of building all of your education marketing. You can actually get your ecosystem to teach each other how to do things effectively.
The one really big danger in all of this platform marketing talk is that you can market the crap out of your platform, and get a ton of people to build on your platform, and then not actually get them adopted in this specific kind of platform. It's really dangerous and really bad and you don't want that to be the case. So marketing is often the team that is in charge of getting the traction part to happen. So the answer to this is drive adoption of your apps.
This totally varies by what your product is. For instance, at Slack we have a bunch of plans on how we're going to do this. We're going to embed apps in the product in really cool ways. So I can't give you exact examples of how to do this other than it's really, really helpful, and even though it feels a little bit unfair at times, to kingmake.
Some simple ways to kingmake: Take the apps that are doing really well on your platform inherently, and then promote them to more customers. It's very simple. Promoting them to more customers means promoting them in products, doing them in email, throwing them in a webinar or throwing them in onboarding documentation.
The way we did this at Box, though we had maybe a little bit less of this, was we ended up working in these mobile apps to some of the largest deals at Box. That's like Auto Trader, these are huge, huge companies. Then we ended up deploying this PDF reader that we had integrated. So we actually just threw it into sales enablement stuff.
You as a product marketer could say, "Hey, Box is great, but Box with apps is even more powerful." Just tell that story, bring it in to the sales enablement content. It's really easy to do.
On Slack, adoption is a bit easier in some ways. We have this app directory. We rotate featured apps every week, and they end up getting a ton of traction even though we don't do a ton of pointing to it. So that's something that we're going to keep on increasing.
Driving adoption is really like a product-marketing-and-product partnership, so the more a product does here, the better and easier it will be for people to get adoption.
One of the really simple things we do is, every time we feature apps, we write a blog post about them. These are the screenshots of the titles of all the featured apps posts. I end up writing them on Friday morning and then publishing them Friday morning every week. If you want to follow along, they're pretty fun.
This completes the Platform Virtuous Cycle. If you don't finish it, it really never pays off to do the platform play. You may get a lot of marketing out of it. You might make a couple partners feel special by being in your crowd and working with you, but you never really get your customers to end up buying more of your product if you never get the adoption piece figured out. So it is critical. Keep that in mind.
Build partner marketing kits. It will help your partners market better. Show them how to succeed. It's super easy. You already know how you want your products to be used really well. Give them best practices. It makes a difference.
Kingmake. The best platforms have all done this. You need to take the ones that are rising up already and are really, really useful to your customers, and have them actually complete that cycle for you. Because not all of your apps are going to be amazing, but the ones that are will really be game-changing.
Drive adoption. Kingmaking is part of the way you do that, enabling it through product, and then helping them be messaged into your customers is another way to do that.
Tell the story, again. This is a super teeny section because it's really obvious. Once people complete the ring around that cycle, you want to tell their story, and that is going to get more developers to build on top of your app or your product, your platform.
This is the story of this guy named Guillermo. Guillermo is a digital nomad. He is a sole developer of an app called /todo. And 25,000 teams are using this app right now. That's crazy. That was our best distribution story yet on Slack. It was one of our early ones, and the guy quit his job because he can now just do this /todo app, and is in Barcelona and traveling around the world.
It's a really fun developer story. Telling Guillermo's developer story to our ecosystem is very, very effective. People read it and they're like, "Wow, if I can get 25,000 teams using my product, I will be in very good shape, too." This shows a lot of hope in the Slack platform. It's very effective.
The biggest thing to do with developer stories is think about your audience.
Guillermo's story is really awesome for people who want to be digital nomads or are building smaller, more lifestyle-sized businesses. We also are going to need to be doing some stories about how larger partners have been super successful on the Slack platform, so that we can acquire larger partners as well.
That is all in the pipeline, though I do not have that product or the results for you yet. If you follow along with what we're doing in platform marketing, you'll be able to see those all unfolding very, very soon.
Just to finalize on everything I've shared here, here's how these four things that I've iterated, reiterated a bunch of times, fit into this Virtuous Cycle. When you have a lot of potential before you and are growing fast and there's a huge opportunity for developers to take with you, you tell the story of it.
Telling the story of it and then some other tactics can help you acquire developers. You then equip them to be successful with you so that they actually get users and customers on your platform to use them. And as your customers are really delighted and happy with their products, you tell that story again, and developers get happy again. And so that is the Virtuous Cycle. That's my story, thanks.
The question is Slack has an $80 million fund for investing in startups that are built on the Slack platform; how does that affect dev marketing and how is that being used? And then the other half of the question is how much of that goes to dev tools?
To answer the dev tools piece, there isn't a certain amount that's going to go to dev tools. But we already have invested in a couple of dev tools, especially because our platform is a messaging platform, and AI and NLP are really, really, really hard. NLP especially. AI's not solved, but NLP in particular is just a very difficult problem.
So we've already invested in some NLP tools because we know that we are going to need good natural-language processing to be an easy API that people can access in order for Slack to be successful, or for the Slack platform to be successful.
Then on the other half, the fund is interesting from a marketing perspective. If you've seen Sign in with Slack stuff, you probably didn't see the Sign in with Slack stuff today, but it was in TechCrunch. And whenever TechCrunch talks about our platform, they're like, "And Slack has a fund." So, like, a fund is a really, really good marketing tool.
We did one at Box. It was, again, a really cool marketing tool. And a lot of funds are vanity funds. Slack's fund is actually not a vanity fund at all. We've made a lot of investments already. We're going to be announcing a bunch of them this summer. We've only announced three, but we've been actively investing since those three that we announced.
In terms of the way we market it, beyond the initial pop, the fund is a dangerous thing to have in your ecosystem. Because if we have a ton of companies that are cropping up doing one specific thing, and then we fund one of them, do we kill the rest of them? That's a very dangerous game to play.
In terms of marketing, and this is something that we are talking about, we just hired a head of the fund who's going to be coming on. We don't want to be too loud about the fund, because we don't want people who are in the ecosystem doing really well who we don't fund to feel like black sheep or like rejected children.
We want anyone and everyone to be successful in the platform, and the fund is just a way for us to help bridge companies that are building on top of Slack, taking the risk to build on an early platform. And that might not get funded and succeed in the longterm. Because it's such an early platform, we want to make the fund a bridge for that and not just something where we take our favorite children and make them successful.
We don't give tons of special privileges to fund-companies. We just invest in them. But they don't have a super different level of access from any other developer building on us. Is that helpful?
Yeah, that is the assumption. We are very clear with our platform. We actually tell any company that we're working with when there's a chance that we could be building a similar product.
For instance, our calls product, we have a calls app within Slack. And we have tons of partners who do calling, and they're still coming. They're not stopping. We were working with a couple of the big calling providers, and we actually just told them, "Hey, we're going to be building calls. We don't think that's going to stop you."
We want to be an equal opportunity platform where our customers get to choose the best tool that they want to use. So if Slack Calls is the most effective tool for them, then they can use Slack Calls. If they prefer Zoom or Blue Jeans, they can use Blue Jeans, and we're not going to try and favor one of those over the other.
We do try to make anyone who's working with us aware if we're building anything competitive at all. And we try really hard to make sure that we're exposing our APIs in a way that makes it equivalent for other providers of services to get chosen by our customers on us. It's a very, very important thing for us.
Fund-wise, it doesn't make a huge difference if you're funded or not for us to give you a heads-up if we're building a similar product.
It was a lot of work internally. A lot of meetings internally and a lot of hustling and getting people to agree that this was going to be a good idea.
The best part is that Stewart apparently has always wanted to make all of Slack's products roadmap public, which is probably not the best idea. So he was super excited that platform was an area that we could do it in.
Having his buy-in made it much easier to be like, "Sorry, everyone's who's doubting this; CEO's really psyched." So that made it pretty easy.
The response has been amazing. If you look at that post on Medium, the biggest post we had done before was our launch platform post and I think it got 15,000 views, which is not wild. That post got 60,000 and we didn't do press. We did not go to press at all, no press outlet wrote about it. It just somehow got crazy organic pickup.
And then if you look at the highlights on Medium, the entire post is highlighted. It's like, amazing, I'm like looking at it, I'm like, feel really proud of myself because I wrote that sentence and there are like 90 highlights on that sentence. So it feels good that the ecosystem resounded so well with it.
Today was the first product that we released out of that roadmap. It was also the one I was most worried about because we launched Sign in with Slack, but we called it "Improved OAuth Scopes for Identity." Really, really different things, obviously. I was pretty worried about that. No one was like appalled at all.
Whenever we add something to the roadmap, we tweet about it. So it's actually creating this really nice thing that we can use as part of our marketing on a daily basis. It's kind of hard at a certain point to figure out what other content to talk about, other than, "This developer's been successful." But when we can say, "New product added to the roadmap." Everyone's like, "Oh, cool!" And they follow along and if we move things over in it. They're excited.
We're going to have to be changing some of the language in it. So I think that this product roadmap thing for platform is going to work for probably a year, and then we're going to have to revisit how we do it.
There's a lot of excitement, and we haven't delivered on this, around developers being able to crowd source what they want to see built on the platform, which you can imagine is popular. I do think that's a really cool idea. We're a little bit too early in terms of where we're at as a platform to do that right now. So we have to do support via Twitter and other things, and then be like, "We hear you. This is the roadmap."
That was actually going to be one of my points in this. I kind of did a brain dump before I put the deck together, and one of the points I was going to make was if you're a small company, be really, really careful. Big companies want to eat you up. They want to use you, and you have to be really careful about how they're going to.
I think that it's kind of the same thing as a lot of what I was presenting around "know what your audience wants."
Know what the developer wants to build with you as the big company. But as the small company, know what's worth it.
What are you trying to get out of the integration? If it's definite usage, and they can't show you proven usage or a way to it, then you probably shouldn't build. If you really want to do a launch with them because their customers are going to be super effective for you. They'll let you have free passes to their big user conference and have a booth there for free. You'll meet a bunch of leads, and it will be effective in having you get a bunch of leads, awesome.
If it's a consumer platform, you have to just look at what's worked in other partners. Because when ad revenue is at stake, you have to think about where the priorities are, basically. I think consumer platforms like this and enterprise platforms are very, very different. The user is paying in one and the user is not paying in the other. So the business model is inherently different.
If you have all the users, then you have to make the user speak for you. The way that we did this at Box, which ended up working pretty well, is that we gave our customers the wording to go make the request to the partner, and it ended up working. Basecamp, lean start ups. They only build what customers request.
If customers are requesting it of you but aren't requesting it of them, just turn it around. Say, "We can't build it, but maybe they can. Request it of them." And you can make your customers get loud enough for you.
Building a really great partner marketing org is a very different thing. One of the most effective ways to get the big players to care about you is to do something with one of their competitors. If they're not going to work with you, sidle up to a competitor, other than like traditional BD, is what I mean.
If you end up doing a launch with their biggest competitor, they are going to come play with you. We did the Lyft thing, and Uber built an integration the next month. It was very, very easy. That sounds mean, but it's just true. It's effective because they care about how they're perceived in the market, and if they're with you or not, when suddenly their competitor starts swimming up against them.
There are other tools to use. At the end of the day, there do end up being a fair amount of face-offs where it's like, "We're not going to build it and you're not going to build it." And then you just wait it out and figure out who it's more valuable to. There are some concessions that we have to make at Slack frequently, where it's like, "This is just so useful to customers, it's worth the dev time to build it." And we make that concession.
Yeah, we are not mature enough yet at Slack to have "Here's our theme for the month," and, "We're therefore talking about apps that do these things." We're really just still figuring out what apps are resonating well.
Generic productivity apps rock on our platform. If you're a generic productivity app, you can go get thousands of users. If you are a content tracking, email-analytics-only thing for people who are doing one kind of content marketing, you're probably not going to get users on our platform yet.
If you're very niche-targeted. In terms of getting marketing in season, if we do Dreamforce this year at Slack, we will probably do some kind of featuring around sales tools in the time frame of Dreamforce. It's going to be a lot of sales-related stuff in that time frame.
Slack is a two-year-old company in a couple months. How it does its seasonal things are still developing. For Dreamforce, their developer event is coming up, and I bet it'll be a good time to do marketing with them pretty soon. It's coming up in June.
I would look at a company's events calendar and see what's effective with them to see if you could get extra juice out of it. Product launches are the other best way to do that for a growing company, is what I'd say.
As the big company, it's really helpful to make the partner marketing kit. Because then you can overview like, "We can include you in a blog. We can include you in our tweets. We can include you in an event booth." You can actually overview your opportunities, which helps sell the smaller company on being interested in working with you.
In terms of coming up with creative marketing, the way that we source that in the two companies that I've worked with is we actually go back to the partner and be like, "What would you like? What would be most effective for you?" And they usually say a quote for press, and we always say no, we can't give a quote.
But then mentions in press, including your assets in a press release for any kind of new product that is coming out, is really effective. I would try and figure out what their prime channels are.
For Slack, for instance, we have all these dev meetups. If there was some way that you could go to a dev meetup and speak to the devs, that could be useful. There are also user meetups that are cropping up around everywhere. And if you want to go to a user meetup and get your project seeded into customers, that might be a really effective way to do it. If Slack gives you blessing to do that, you can come into the user meetup and be like, "Hey, I was told I should speak."
So, I'd look at different marketing channels. I'd look at events. Blogs are a really obvious and easy one; you can get mentioned in a blog somewhere and linked to. If they have an app directory, always ask for being featured. Because if you just put the request in, the team that reviews the apps that get featured, whether it's Apple, down to like something that's brand new and really small, they'll think about you a little bit, at least. Squeaky wheel gets the grease.
I could brainstorm more with you later and go through what we've done previously, but a lot of it ends up being how you do Twitter, blog posts, simple marketing stuff like that.
If you wanted to run a paid campaign and use their logo places, stuff like that can also be interesting. Quip launched with us today. They ended up doing a ton of paid campaigns on Facebook, which is super interesting for us to see and be like, "Cool. They're like using our logo there." And we're cool with the fact that they went really big.
It's currently changing. When I joined Slack, it was 260 people, and now it's well over 400, and that was eight months ago. So the team's really changing fast right now. At Box it was totally different, too.
We are currently moving the Product Marketing org at Slack into Products so that it's super embedded with the Product Teams. And then Platform Marketing is within Product Marketing, and we run Development Marketing, Partner Marketing and then Platform Product Marketing.
If you think about the four categories that covers, it's like creating a really useful large partner marketing program creating really good developer marketing content. That's everything from just normal thought leadership and content marketing to equipping them with education.
That's usually partnered with DevRel really closely because I can't tell you how to create a bot from scratch, but I can get you someone who can, and then package it nicely. It's product marketing, so explaining the products to developers.
It's also customer facing for us for Slack, getting our customers to then adopt the apps that are built on top of Slack. You probably saw on my deck, that's the step that we're still stepping into right now, to figure out like where we embed.
Right now there are just some barriers in product that we want to solve so that we can then go really hard on telling customers, "Hey, you're trying to do this thing. You should totally use an app to do it." And install should be one click. Right now it might be like five clicks, so when we get it back to one click, we'll start doing customer facing marketing.
Does that help, to do the four different functions? This varies by company, totally different depending on the team. I think that's the case with Product Marketing. Product Marketing can live in Product, Product Marketing can live in Marketing. It's kind of a funky marketing role for that reason.