🎬 E23, Part 2. Growing a SaaS marketplace is VERY CHALLENGING even for companies like GitHub. We discussed a tricky path to platform success with Corey Hobbs, who launched GitHub Marketplace as Platform Product Manager and is currently Senior Product Manager in Adobe, working on Extensibility and Platform. 🚀 Part 1 is here
- I would imagine that there was a time when you launched a marketplace in GitHub and you had certain success. But typically success doesn't come in one straight line, it is typically step by step process. How did you grow GitHub marketplace and what was your learning there?
- I'm a person who loves to learn by trial by fire as the saying goes [laughs]. When we launched the marketplace at GitHub it was May of 2017, a big user conference. Around that month there was a ton of traffic, a ton of revenue subscription that came through, because we had a massive user conference where thousands of people were watching in person or online. And then typically with any product launch you have that first initial peak and then you go, I don't want to say you go into a bear market, but you really figure out who your real customers are. After the free trials are done, after these free activation periods are over, after all your paid marketing and SEO things for that first wave of the campaign are done. You begin to really see, okay who's the actual persona that we're building this thing for? Or is the persona that we thought we were building for actually true? Are all these hypotheses that we had around this marketplace true? And we didn't really start to see, I guess you could say, light until realistically 10 to 12 months after we launched the marketplace. So when we launched it, a ton of traffic, ton of revenue off the beginning and then a lot of people either cancelled or their trials ended, they didn't renew. And then just eventually the hype engine, I guess you could say, kind of died down. And then we really just had to go back to the bare metrics of "okay how do you build a great platform? Let's make it easier to one list a new product in the marketplace, let's make it even easier to build a product for eventually getting it on the marketplace. And then we completely restructured our documentation. Where before it was saying "hey here's how to build a thing to extend GitHub" to "here's how to get listed on the marketplace". Where you're still building a thing, but the eventual goal that we're trying to funnel everyone through is you need to build these things so you can get on the marketplace. And the other side of it is when we launched we had very restrictive constraints or very high requirements to be listed on the marketplace. And once we figured out who the customers were and who the right partners were, what was the right engagement model, we actually made those requirements a little bit softer or a little bit less stringent to open up the top of the funnel. Often in sales or in strategy people talk about the funnel getting down to the point of precision of who's going to really be with you for the long haul. And once we made those key changes to documentation to making it easier to build on the platform and also making it easier to get on the marketplace, thus opening the top of the funnel, that's when we literally saw like a 10x increase in the number of listings on the marketplace. Going from double digits to triple digits in the span of 90 days. And then the next phase for us to really hit home on your question of how we got through the phases and eventually to the growth phase where it was just up and to the right every single month, we really doubled down on strategic partnerships. So after a year's time we had enough data and information of "okay who's been the most successful on this platform, who's made the biggest deals, which partner had the most customer growth in this certain amount of time?" We struck a couple key strategic partnerships, doubled down on the enterprise and then our revenue doubled. And when I say our revenue doubled it literally happened overnight. Once we figured out who were the real winners and where were our customers needing the most help in terms of figuring out how can we bundle, and this is one thing that I really try to help folks on thinking about when they're building out of marketplaces. At the end of the day your customers want to solve a problem, but they don't necessarily know what they need to solve it. And when it comes to marketplace what I learned is you often have to bundle these services and tools for your customers, so they can buy them all at once. And one of the key things GitHub did around that time is simplifying the checkout experience to make sure procurement teams at our customers companies were able to just buy it once instead of buying several tools separately, going to procurement illegal and GRC and all of that. But yes, once we did that, just again: documentation, lowering the barrier to entry, and then focusing on the enterprise, that's how we got through the initial climax, went through a very rough time for about a year and then we made that that strong pivot to support the enterprise and things took off from there.
- In terms of learnings, I'm sure that you see a bunch of people trying to build platforms, and you're doing it again and again yourself. From your observations, what do you think people most often do wrong? What are the mistakes that you think are repeatedly done by companies?
- First I'll start with some of the things that I think I've done wrong, or teams that I've been embedded in, that we've done wrong together. I think one of the biggest ones is that you make the wrong assumptions based on how you would want to use the platform, if that makes sense. I've often been on teams, where it's like "hey we have the API, the platform's here and let's build a marketplace. Because when I'm developing I want to find a tool very easily and here's why I think I need it". If you work at the company and you use the product outside of work for yourself, you are not the ideal customer in my personal opinion. You really need to get out into the field and get a massive amount of user research and user interviews to really get all the varying personas and identities to get again the thematic view of how people are actually using your products in the wild with the information that's publicly available. I think that everywhere that I've been always made that mistake. I don't know why I keep making the same mistake, but I think it's just a human nature. It's like "Well, I use this thing, I know how it should best be built". Whereas at the end of the day you're not paying for your own software. Someone else, some CIO or an IT manager or a CSO, someone else is paying for this thing and they're making a decision that's going to affect a hundred or a thousand or ten thousand employees across an organization. So again, getting out in front of your customers and really either recording the screen when you're doing the user research or the walk-through of the demo and really just understanding how that usage pattern happens. I think the other thing is again on the same case of making the wrong assumption, is making the wrong assumption of what people actually want. I've often seen even for myself, where I'll be doing user research or user studies and even the way that my questions are structured are kind of biased or the little bit of leading questions, which gets me to where I want them to think about the solution. Whereas again just taking a step back and having them just explain how they use it in a given week, and what they would want out of the thing, and not even asking or even pitching or suggesting any solutions at all. It's like "all right thank you for your feedback, I will follow up in a week or two or a month". Because I think again you could come in with this great strategy, and you obviously understand how your business works and all the levers that need to be pushed or pulled. But at the end of the day your customers may be completely at odds with what you're investigating on the inside. So those are the top two things. There are a ton of other technical and strategic things that you could look at. At the end of the day really work with your support and sales teams to get in front of your customers and literally as a product person at least just listen. Don't offer solutions and say "hey we're going to change this, we're thinking about building it this way", Because now you're biasing the customer's mind and them believing what they think they want. And then on the other side, just don't assume that you are the ideal customer, because 99% of the time, that is untrue.
- It's really fascinating, because I think every time when I make a hypothesis what customers think, I'm more or less wrong almost every time. And it's I think the most difficult part is to keep silence when you speak with your customers. Because you tend to assume that you know something, but actually they see everything from a very different angle. One other thing that I've heard actually to share on a personal note is about marketing. So the best advice is don't even try to write any copy, just go speak with your customer and write down what they say they want. And later tell them back what they say. I saw this actually worked like wonders. My last question is I'm sure you're thinking about the future of platforms and how this will evolve in the next like three to five years?
- The first thing that comes to mind that everyone in my professional network at least and even across the place at Adobe right now. I think one of the themes that's coming out of all those conversations is that identity and access management will be one of the number one requirements in terms of a great user experience. That will be required to have a great platform or a great marketplace. And what I mean around identity and access management is one, if I'm a developer or a creator and I'm creating a plugin or something that's extending on your platform, it should also be very straightforward for me to share that project with someone else. So if we again think back of the GitHub model of collaborating with a peer or a colleague on that project, whereas today if you're building a Facebook application or even a GitHub app or an Adobe app or any of these modern platforms, it's a very singular platform. In the case of you Roman are building a plug-in, but no one else in your organization can also have access to the development of this thing. And I think a lot of that will change as we begin to think about access management and role based access controls. As a lot of these more antiquated software businesses have their digital transformation and come to more modern software platforms, they will understand and already have the requirements that my entire team needs access to this platform in a ubiquitous way. And on the other side if you think about it from the customer's perspective, in the future, and I've already started to see this in platforms that are built outside of the Western world or in the American dominated market, is from an identity perspective there's no reason why I should ever have to put in my credit card information again. Like once you have it the first time when I get to a checkout screen you shouldn't ask me for my credit card number, you should already have verified that I am me. In the same way that you can acquire an application or an app on your iPhone or your Android phone, I think users even in the enterprise will have a soft or subtle expectation that that will translate to platforms as well. So the same way you're working in context in Photoshop or on GitHub or on Jira, you should be able to pull in plugins and extensions in context wherever and whenever you're working, all the way through the payment and subscription of that extension. I think again on the identity is access management that will be one of the number one issues. I think the other piece is if you really get into the weeds of building out platforms or apps, there's a lot of talk on "oh it's security and OAuth and is it an extension, is it an add-on?" At the end of the day in my opinion customers don't care if it's a plug-in, an app, an extension, an add-on, a widget, a PowerApp. All these terms are marketing terms, they just want the thing to work. I think we'll hopefully see across the industry those terms be pulled back in saying "do you want to enhance your workflow, do you want to enhance your experience, let's say?" And I think someone who's doing it fairly well, I don't want to say it's the best, but in the enterprise space or in the business consumer space Slack does it very well. On the back end, if you're building it, they do make a distinction between an integration and a Slack app, but from the user's perspective, these things work ubiquitously. And the easiest example is if you and I are in Slack right now and I share a Google Drive link with you, Slack will automatically detect that it's a Google Drive and then it will automatically prompt you to install the Google Drive application. The prompt usually says "hey, we noticed that this from Google Drive, do you want us to remember this setting?" And they don't even necessarily phrase that it's an integration. If you click YES they'll sign you in, and then now you have the Slack to Google Drive integration without ever really being asked that it's there. And again, I think it's a really nuanced way of helping you get to that end state as a customer, at least in terms of what you want. So not to go too deep into the question, I think on the surface that's what's going to change the most - identity and access management for the developer side as well as the customer side. And then on the second piece is, from a customer's perspective I don't care if this is an app, an extension, an integration or PowerApp or whatever, I just want this thing to work with what I'm already using. So I think those are the top two things that are really scratching the surface.
- Fascination sorry and congrats on this journey! I'd imagine that actually took a lot of directing efforts across all parts of the company, right? I'd imagine that it took involvements of different departments and buy-ins from marketing and everyone else. How did you do that?
- The simplest way I can answer that, and it seems like it is playing out everywhere that I'm working, especially at Adobe now, is really working early, before I even start building the product or building out the platform itself, to make sure folks are bought in. And for all the coordination pieces to happen is really just offer up my time to help solve a lot of the old issues that the teams that I'm going to have to depend on to help me build this awesome platform and marketplace experience, I make sure to help them first. So whenever I come back and I ask for a big ask, the blow is kind of lessened a little bit. And I make sure to try to do that everywhere that I go to just buy me a little bit of credibility, saying "hey, remember these last three or four things that I helped you out on? Cool, now I have one really big request to that I need your help on for the next two years". Because the other thing is when you are building on a platform or a marketplace, it is a very long strategic investment and you need to ensure for yourself, and for your team, and for your customers, that the folks that are going to be building this thing will be around for a long time. Because at the end of the day if you're a partner and 90% of your business is dependent on this platform, you need to make sure that the people you're talking to are going to be around for a while. To ensure that you have a little bit of a safety net to make sure you can continue building with those folks. So you have the same amount of credibility again yourself as a partner.
But personally again I try to make sure that I offer up my time and services and help and hopefully skill set to teammates and colleagues internally to get that credibility. And then also when I am helping them, I start to pitch this idea of like "hey we're thinking about building this thing, can I get your feedback? What are the issues that you've been facing in the past around these things?" And I start again building out those themes internally. So similarly to what I do for customers, I also do that internally, to make sure that everyone's aligned, whether they're in the company or outside the company. To make sure I'm building the right things. And around the time that we get to actually writing requirements and getting everyone in the room and having that big first workshop meeting, 90% of everyone in the room is already on the same page. It should rarely come as a surprise that you need or want to build a platform or a marketplace, and also how you're going to get to that end state - that needs to be clear from the beginning. Otherwise you could build something completely arbitrary and it may not actually help your business in the way that you had hoped.
- I cannot omit asking you about monetization of platforms. Because these companies acquire a lot of data from customers. One of the attributes of platform play is to pull all this data in one place. What do you think going to be examples of the future ways to monetize all this data in the right way?
- I think we'll start to see a lot of platforms become service platforms versus app or add-on specific platforms. Today most marketplaces, at least that I see, it's you're using Jira or Atlassian and you buy an add-on that may be free or cost a certain amount of money a flat rate or per month and then you pay for it that way. And the service is you may pay a different price depending on how
much usage per month or per year. But that general pricing notion where I've started to see some businesses like Heroku, AWS and even something that's a little bit more consumer focused, which is GitHub actions, I believe they released it around two years ago, but they're paying you per event run. Or a better example may be If This Then That . If you use a paid version of IFTTT where for every time you use this thing it's a fraction of a penny. Because I think often you'll pay 8.99 or 25$ a month for a service, but you may only use it that's worth five dollars of that 25. And it's great for the business, but at the end of the day I think a lot of consumers are getting a lot more savvy around how they want to spend their money. And I think those requirements will start to play out on the monetization side, where we'll start to see the pricing structure of how platforms are monetized go from "hey, pay 30$ a month to have access to this thing" versus "every time you run this we're charging your fraction of a dollar, a fraction of a penny". Which in my hope makes platforms more extensible, because they realize "okay for certain things that may involve AI or machine learning we can charge you a little bit more, because it's more of a GPU intensive operation. But if you're just storing a file, we may only charge you 0.001 of a penny to store this file." I think that's maybe it's too far off, but I think that could be a way that platforms start to monetize in a more straightforward manner.
- Brilliant, now that you mentioned AI, it opened up a room for the entirely new conversations sometime in the future. [laughs] I really appreciate your time and thank you for your insights. Knowing that you are in Adobe, which is already a great product, raises my hopes that it's going to be even better in the future. Thank you for very detailed examples and explanations of how everything works.
- Perfect, thank you Roman. Until next time.
Part 1 is here
Comments