🎬 E23 with Corey Hobbs, Senior Product Manager in Adobe where he is working on Extensibility and #Platform, previously Platform Product Manager for the GitHub Marketplace. 🚀 RARE OPPORTUNITY to hear directly from the PM who has turned SaaS products into successful platforms first-hand. Part 1/2
- Corey, I’m excited to speak with you, because you’ve worked on such amazing products like GitHub and Adobe, where you worked on platform creation out of existing products and building extensibility. Can you share in a few words how you started to work on platforms, and a little bit about your experience in this space?
- As I started to try to figure out where I thought I wanted my career to go, I think at first platforms started to make the most sense for me given my past experience as a developer. And I often built on top of APIs and platforms when I was learning iOS and Android development. I mean so often when you're building applications like that, you're working on top of a platform and you realize the 10X factor around building on a platform. And for me I was a little bit tired of being on the outside. And I wanted to be on the inside to help folks like me who struggled with API documentation, who struggled with getting the right contact inside that company. And I just really wanted to spend a lot of my professional time building up great platforms that are already existing and bringing some of my knowledge as a developer to the business or the product side of the house.
- Obviously almost everyone knows GitHub and many use GitHub. GitHub was a very successful product before it was turned into a platform. On the example of GitHub can you explain what is the difference between a product and a platform?
- GitHub as a product, again as you mentioned most or everyone should at this point hopefully know what GitHub is at least in the tech landscape. As a product it's a software collaboration platform, some folks say it's the Dropbox for code. So if you want to partner with a buddy or a colleague or classmate on a software focused project then 90% of the time you'll be using GitHub to do so. On the platform side it's taking that same concept of coding and collaboration and connectivity and bridging the gap to other tools, pipelines and plugins. An easy example is you and I are building the next cool consumer app that's going to take over the world. And we realize that "hey we actually need some integrations to touch AWS, or to touch Heroku, or to touch some of our analytics or error systems, and that's how GitHub the platform came to be. When we started to add a lot of these apps or extensions to the core experience to build out that workflow.
- When you started, GitHub already had a pretty good API I would imagine, right? What is the difference really between a product which has an API and maybe starting to have a handful of integrations versus actually a true platform?
- I think the delta is, believe it or not, most modern software companies have an API that doesn't necessarily make them a platform. So the way that most modern software is built is you have an infrastructure team or back-end team that some folks call it, and then everyone else. That's middleware or front-end or the design or the other side of the house. And a lot of those teams need to bridge that gap with internal APIs. When they realize the utility of those APIs, they understand that customers or partners that want additional features that maybe that core product team will not build or cannot build at the time, it makes sense to turn those internal APIs into external APIs. And that's I'd probably say the general case for 80 to 90% of SaaS or software businesses. You take an internal process or API and you give it to the public. You put some security provisions around it, you put some rate limiting around it so it's not abused, and then they have that. It doesn't necessarily make you a platform when your API in the developer ecosystem or the partner ecosystem that you're starting to curate upon making the API public. When you turn the faucet on or that inflection point to become a platform is when you start to, one you first hire specific resources for the external facing parts of the API you hire a professional team of writers or staff folks who are writing API documentation and the other part of it is that you actually start marketing. When you go to your next customer, let's say it's Acme Corp and they want to buy your core product, let's say in this case GitHub and they also want some of your partners' tools because they've seen folks use the API in very cool ways that extend the product that's when a platform starts to form. When you begin to package the benefits of the community alongside your product and sell it into your customer seats or base, I think that's when a lot of companies start to turn from just "oh we have an API" where "we are now helping the ecosystem I guess at large to sell across our platform".
- When you start thinking about turning a product into a platform, where do you start?
- That's a really good question. This is something I think about very often. There are times, like right now I'm facing the same issue where we have a couple features or products where it's like this should just be a platform. And I think it's generally a difficult conversation because in my opinion supporting a product is a lot more straightforward and a lot easier in some cases, than supporting a platform that does a lot of the same things. And generally platforms should do more than just that core product. And I think to answer your question “when do you know when or how to turn that product into a platform”, I think it really comes at the rate of customer requests or partner requests. As you start to sell to more folks across the industry or more people start to reach out to your support team saying "hey, this thing is broken" or "hey, can this part of the product expand or extend to do this certain thing?" And you start to get a lot of these requests that become thematic in nature. Where like the same types of questions in a specific category or the frequency of how they're asked or when they're asked increases. And then in my experience at least that's often when we start to open up the product and turn that piece into something we can share on the Platform. First starting with an API in a beta or private release fashion and then we open up to the general public for the platform. But it really comes down to what is your sales team is hearing from the field, what is the support team seeing in the email inbox, and what they're hearing from customers. And also given if you're on the product side of the house what are you hearing in customer surveys and user research and all of these things becoming thematic in nature. And if they are, then it should be a very easy "okay, this part of the product, we can make this extensible, open it up to the platform and let people profit off the backs of what we've built here".
- You're basically saying it's a customer driven and partner driven, right? In one of your talks you mentioned building a case for management as a product manager to build a platform. What was your experience of building this case in one of your previous companies, like GitHub for example?
- Almost in every company where I've worked, building the case to expand the platform and invest more resources and hire more folks onto these teams, it definitely comes with pitching it upstream to your VPs or directors or SVPs or even in some cases your C-level executives. And for me the thing that I usually try to pivot the conversation on is one, we will as a business save money by not having to build these features out and hire more engineers and hire more designers and marketers to build this product and then market it and then more people to sell it. On that part of the Front, it's a very simple business case, where you're going to save money because you're not building this thing and you're now putting the benefit and responsibility in the hands of the ecosystem. On the other side of it, the one example that I often pitch is the iPhone would not be this world lauded great product that we all know and love, or at least most of us do, without its ecosystem or its application ecosystem. And if you're building your platform in the right way, and I truly see the iPhone as a platform not necessarily a product, you have to start to think of your own product the same way. Whereas if you do it right and you make certain parts of that product or that platform extensible, the community will come. They will build the things that you're looking for them to build that you can't or will not build yourself due to time or constraints or just maybe it's not in alignment with your strategic mission of whatever you're trying to do as a business. And those two specific points that I generally bring up and obviously it's supported with data and what's going on in the industry and competitive analysis that usually hits home very very early. And if some of those points are a little bit weaker, the last thing that I usually come back to is "well if we can't get to this now let's open this up as a beta, we already have the API internally, because it's a product let's give this to 10% of the community and let's see what they build in the next quarter and if it surprises us might as well keep it around, if not then we can basically tell them "hey this is part of a pre-release beta program anyway" and we could roll it back. Again, one - give them a business case, two - give them the competitive landscape of what's going on and enable them to understand what we gain as well as the community and our customers. And on the third point say hey well if not, let's test this out and if it works we keep it if it doesn't then again it was a beta so there's there's no real risk around showing your hand in that case".
- I really like that, doing step by step and testing the water. Talking about whether platform play is for everyone, and we asked this question to many different people, I think it would be very interesting to hear your thoughts on this. Is platform play for everyone? And if you're thinking about building it, what is a timeline you would recommend guys to think about?
- The shortest answer, and I get asked this question a lot, I personally don't believe a platform play makes sense for every business. The easiest example is if you are a partner company that, I don't say the sole purpose of your business, but the sole premise of your business was built on top of a platform. I don't want to give a specific business example but if I am Acme Corp and I am built on top of the Adobe ecosystem and that is the depth or breadth of my business. Like I only integrate with let's say InDesign server and I'm a print machine company and that's the basis of my operation, I don't think it makes sense to then in itself to turn my business into a platform. That just doesn't make sense over time in my personal experience. But I do think if we just take a step back and look at the 10 000 foot approach, I do see a lot more businesses radically or dramatically shifting from a product or services based business into a platform, as we begin to see a large part of the world go towards API first, instead of product first. If we go see a large facet of businesses trying to take a step back and say "you know what, we don't want to build this thing". I would be very surprised and I've kind of already seen it done, but there are plugins that work with Twitter to actually have an Edit button, which is the long waited feature that everyone in the world has asked for on Twitter "can I just edit my tweets?". There's actually extensions that work alongside Twitter's platform and the API that allow you to do that. Well, do I think Twitter will ever do that themselves? I'm unsure, but the reason why I'm bringing that example is I don't know if the company who built those features as part of the ecosystem or the platform I don't think those will ever become platforms themselves. I don't think they would ever become competitors to Twitter, given the sole purpose of their business was to extend Twitter's core functionality. But the second part of your question around if you were pivoting or even just thinking about building on a platform, what's the time horizon or maybe the first two or three things to think about? One, the time horizon really depends on where you are at today as a business. If you already have an API that's publicly available, you are 10 steps ahead because you already understand what's realistic for your company in terms of "okay how many folks are utilizing our API, do we already have the infrastructure and the management and the resources to support this API? Going from, okay a thousand people use this today versus a hundred thousand people use it tomorrow. I will take a quick note just to really drill in on the infrastructure piece. We saw this at GitHub we're definitely seeing this at Adobe and I definitely saw this at a smaller startup that I worked at in the past, Particle.io. At any given moment that one CNN piece on your company or Techcrunch article or whomever, it could just be a simple tweet. When someone catches wind of your business in a really good way and they shine a light bright on it, you could really 100X your platform overnight. And I think that's the thing that we often don't see with products, where it takes a very long time for your iOS app to reach a million users. Whereas you could have a million requests a day or a million requests a minute for your API, once people realize the utility. So really focus on your infrastructure. The second thing is the only documentation is good documentation, everything else is just words on a screen. And I really want to hit home on that. I've seen platforms burn to the ground because their documentation was so poor, the support teams were so overwhelmed that they actually couldn't build anything new and they were only ever doing bug fixes. And a lot of it was just confusion from how the documentation was written. To keep this brief, those are the first two things I would focus on. Obviously you can look into the customer use cases, what parts of the API to extend what makes most sense strategically as a platform and direction to go. But one, just making sure in any direction that you go that you can scale from an infrastructure perspective. And on the other side that you're actually set up for good documentation and good developer evangelism and marketing to make sure that side of the business can be self-efficient. And generally on a time horizon I think a solid platform could be built in six to nine months. It's extremely fast, but that's also if your business already has a public API. If you're starting from scratch, well over a year. It's a pretty long time. You can always start with one core feature set, like if you're a file provider or whatever just only start with your upload API and extend from there. On the very fast side six to nine months, realistically about 12 to 18.
- It's very good advice regarding documentation and public API. In terms of measuring success of a platform as well as managing and growing it, I would love to hear your thoughts about how you did that? What was your learning and what was the role of partners in this process?
- I think when it comes to measuring success in your platform, everywhere that I've worked it generally starts with the note that I mentioned earlier around what are the themes of your platform that you're trying to imbue or or build out or structure yourself upon?
And some of the easier ones is one, how many support tickets do you have on these specific categories? It's often like "oh the rate limit is too low" or "this piece of the API is broken" or "we want to do this specific action". And honestly a cheap and easy way again to build is just go after those things first, measure how many let's say support tickets you're getting in a span of a month or a quarter. Once you release this part of the platform or the API measure that same metric on the outcome on the other side of you building it. I think a little bit more strategically If we're thinking about a platform, just taking a step back I think often I personally even frame this only in the context of you're building a platform for your developers they can build a business on top of the thing. But ultimately a platform for everyone is meant to extend your business or product to meet the needs of your customers, not necessarily developers who want to create a cool extension or shortcut for the workflow. Everywhere that I've worked, we've always measured what's the actual customer outcome, so how many deals won as a result of us building out this feature or facet of the platform? How many new customers have mentioned like "oh yeah I actually use this plug-in with this product". And I think that's something that, at least in my experience, a lot of our enterprise customers are often mentioning and say "hey, does this part of your product integrate with Google Drive? Is this part of your product to integrate with Slack? Do you have a plug-in to Jira? Do you have a plug-in to GitHub?"
And just simply measuring the uptick in anecdotal, obviously it can become quantitative, but in terms of how many customers are starting to actually mention your platform or the ecosystem around it as a deciding factor is why they chosen your product or business. And that's the easiest one to tell your VPs and your executives because I mean obviously it's more revenue for the company. And often for the sales reps it's a lot easier sales cycle. And in my experience it shortens the sales cycle. We're like it integrates with this, we already use all these same tools and services, we're ready to go let's make the transition. The other thing is we really look at usage KPIs, what's the percentage of our monthly active users from this demographic is using a thing. Discovery metrics obviously like page views in general things if you have a marketplace. But the easiest one to look at, again, is the anecdotal and eventually quantitative data that comes from customers mentioning your platform or ecosystem or marketplace helped in their decision making process to buy your service. And then the other one is, what I mentioned earlier, is the number of API requests per day. So as you expand your platform and or marketplace you should see a thousand API requests a minute eventually growth to ten thousand a minute to a hundred thousand a minute to a million in a minute. And that's how you can easily just see like okay this thing is actually becoming beneficial.
- In one of your talks you mentioned that building a platform out of GitHub helped a bunch of partners raise a dozen of millions in venture capital, which I found really interesting. Can you share one or two examples, maybe not mentioning specific companies?
- Definitely. There were a couple times shortly after we launched. When I was at GitHub, we launched the GitHub marketplace back in 2017. And around that series of announcements there were some smaller startups that had long been partners on our general platform, but we didn't have a formalized marketplace. So it was often hard for enterprise customers to find the actual solution they were looking for. And leading up to the launch of the marketplace, we started to introduce some of our largest customers to some of our smallest more nuanced niche partners on the ecosystem side. And not to give away too many specifics, but in some cases these were six and seven figure deals for us, which also translated to high five and high six figure deals for our ecosystem partners. And if you're a small startup and you generally have a couple hundred customers who are paying you, let's say eighty to two hundred dollars a month and then all of a sudden you have five to ten mega customers who are paying you a hundred thousand dollars a month, that drastically changes the projections of your company, the value of your company. And now maybe the same investors who may have told you no in the past "you need to grow your story and figure out who your customer is". Just us helping these partners come into our network and our ecosystem, building out this marketplace and giving them a storefront, I guess you could say, drastically helped their business. And literally overnight they were emailing us saying "hey, can your head of business development join our investor call just to confirm that we're partners with you and all these things are true?" And there is a fair amount of companies who raised anywhere from a million to 50 millions, some have been acquired since we launched to get a marketplace and a lot of that has come from the success that they've had with the close partnership of the GitHub platform and ecosystem.
TBC in part 2.
Commenti