Untitled

Discuss this episode in the Muse community

Follow @MuseAppHQ on Twitter

---

Show notes

00:00:00 - Speaker 1: I think every platform kind of has this tipping point where you start to see like, hey, this feature, this product is getting a lot of traction, and people building on any platform should realize they are doing R&D for the primary platform at all times. Every feature you release, every experience you have is an opportunity for the original platform to be like, hey, that’s a great idea.

00:00:29 - Speaker 2: Hello and welcome to Meta Muse. Us is a tool for deep work on iPad and Mac. But this podcast isn’t about me use the product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with my colleague Adam Wulf.

00:00:43 - Speaker 2: Hey, everyone. And joined today by Joe Watkin.

00:00:47 - Speaker 1: Hey folks, great to be here.

00:00:49 - Speaker 2: And Joe, you have an interesting background with creative tools including GitHub and Abstract, you’ve had your own startup doing calendar slackbots and other calendaring things, but before we talk about all that, I’m very interested in your side project ballot share. Can you tell us about that?

00:01:06 - Speaker 1: Oh yeah, yeah. Ballot share is a is a labor of love.

It’s much less of a business than a fun project, and it really just centers around helping people get more information when they’re about to vote.

And so, People usually want to vote for one or two things when they hit a ballot, but it’s all of the minutia stuff that people don’t really have a really good sense of what to vote for or who to vote for on really local issues, but those are the stuff that really, you know, impacts them. And so Ballot share is just a site where you can see who’s endorsed things all the way down the ballot to like your local city ballot initiatives. And you can also create your own endorsement around things that you think are important and share that with friends. So the most common use case we see is people say, oh, like I have a friend who’s really plugged into education, so maybe I could ask them who to vote for for the school board president. And so they send you their endorsement and you kind of see it in a grid where you can kind of compare all of the endorsements that you want to compare. It was built for the last election cycle and we’re hoping to revive it again for the midterms.

00:02:14 - Speaker 2: I really like that idea of a sort of using your trust network if that’s the right way to put it.

Maybe we get some of this implicitly, you know, there’s people I follow usually like substack where they do political analysis and to some extent I’m sort of trusting if I’ve come to trust that their analysis is good in some cases it’s that I’m reading their analysis and better understanding the issue, but in some cases it’s that I go, OK, this person.

Seems to be pro this thing and I basically trust them, so therefore, I’m gonna kind of outsource that decision a little bit, especially for, as you said, all these finer details and local things that maybe you can’t deeply research each and every item.

So it feels like it’s naturally what people do anyways. So as a tool to help you kind of reach that.

00:02:59 - Speaker 1: Yeah, yeah. A lot of people end up making like Excel sheets and then sending them around.

And it’s actually kind of funny, we noticed that it’s not just wanting to know who endorsed it, it’s who is against certain things.

So when you see like, hey, this group is against it, you’re like, that’s surprising, why? And sometimes it takes like, hey, of the 10 ballot initiatives, 6 seem like everyone is in agreement, but then like maybe 3 are kind of like up in the air. And so you, those are the ones that you personally investigate. So it kind of just puts more time to the ones that you think are actually worth the the decision to make sure you get it right.

00:03:36 - Speaker 2: And tell us a little bit about your background.

00:03:39 - Speaker 1: Yeah, so I’ve done a lot of work in the tech space, but it’s not always specifically on the tech side. So my background is I came into tech via sales actually. So I was hired at GitHub as one of the first technical minded sales people, and GitHub was a very weird beast where there were no managers and you kind of like had to understand how to do a pull request to like even do anything in the company. So, I originally did Git Up sales, focused on the enterprise clients, but switched over to BD at GitHub, maybe my 2nd or 3rd year, as just a hugely undervalued piece of the business.

00:04:16 - Speaker 2: And I’ll briefly unpack that BD stands for business development, which I think itself is probably not a super well, in my experience, it’s not even a super well understood title slash function, so maybe you want to briefly describe what that is.

00:04:31 - Speaker 1: Yeah, absolutely. BD means so many different things. It’s kind of funny. I think a lot of startups tend to use BD as just another name for sales directly, like generating revenue and talking to customers.

At GitHub, it was a little bit of a catch-all, so I was running sales partnerships where we partner with companies like Ubico and get more people using two-factor keys, but it was also partnering on the technical side. So working with companies to maybe build a plug-in, and specifically my charge was everyone who’s using the API helping them do their job better.

And at the time it was mostly just like a ragtag group of maybe a couple 100 people using the GitHub API. They had a very open, very public permissionless API at the time, so people just, a lot of researchers, a lot of students, but then like a handful of companies who are trying to build a business. So my job was a little bit more. Focused on getting that group of people to be more successful, and the sales partnerships happened, they were just much less of a focus, and it was a small team, we maybe had 6 people max, so we kind of did a lot with a little.

00:05:40 - Speaker 2: And you had the same title at Abstract, if I’m not mistaken. Tell us about that experience.

00:05:44 - Speaker 1: Indeed, yeah, Abstract is a funny company. They do version control for design files, and BD at that company was much more around product partnerships and mergers and acquisitions work, M&A work. And so we didn’t do any kind of like sales partnerships. We specifically focused on anything that would help the product be a little bit better, and then kind of fielding the requests and inbound we were getting from interested parties around M&A work. And so that ended up being a lot of work when we got acquired by Adobe, but it was a pretty fun ride as well.

00:06:19 - Speaker 2: And it seems to me version control is by definition part of a tool chain, part of a stack, so those partnerships and integrations are crucial because that is the whole sort of reason for existence for the tool, and I assume there’s the technical integration, but then making those business partnerships where you’re doing something together, maybe that’s co-marketing, but maybe it’s also you’re trying to serve the same set of customers together even though you’re two different companies making two different products just from the outside it seems to me like that would be a crucial function.

00:06:49 - Speaker 1: Yeah, it’s definitely an important one. In both GitHub and the, you know, abstract case, these are part of a stack like you mentioned. People are considering entire tool chains, and so we’ve got to work nice with everyone and also try to help the group itself be better cause I think there is this constant struggle in the sass world of, you see companies who want to go single suite and company offer everything under the sun, like an Atlassian or Salesforce is another one of those.

00:07:16 - Speaker 2: Microsoft is the absolute king of this, right? You sign one contract, and you get a whole suite of mostly mediocre products, but it’s OK because they fit together and, you know, you could kind of buy one time and everything you need in the software world is kind of taken care of.

00:07:34 - Speaker 1: 100%. And then you see the opposite swing where it’s all best to breed, where it’s, hey, I really care about getting the best tool for this, even if it costs more. And we see companies swing between the two quite often. So whether it’s cost related or maybe it’s, you know, new leadership, it’s like, hey, we really care about developers, let’s break out of this like low cost tooling and now give them like stuff that they want to use. So in both cases in Abstract and GitHub we were kind of managing in the breast of breed world where we were working with partners who are, you know, all trying to serve similar and shared customers.

00:08:08 - Speaker 3: And an abstracts case, if I understand right, the design files are mostly probably opaque binary to some degree, and so they would not fit very well in a git style version control, and so that’s where the abstract steps in for that really special case of potentially very large, very binary. Difficult to diff files, is that right?

00:08:31 - Speaker 1: Oh yeah, absolutely. I love talking about this cause it’s like real deep and kind of amazing that as you exactly said the Git is more suited for plain text files and You know, there are things like LFS and Git that, you know, have pointers and allow big binary files to be version controlled, but it’s really hard. And so this is exactly what Abstract it, is that they saw Sketch was market leader, but they couldn’t solve this one piece around versioning because of these big binary blobs, and so they created an ingenious solution that actually did use Git on the back end and stored this enormous corpus of design information. And was able to kind of parse through the binary and pick up changes. So, at the time it was revolutionary, you know, there was literally nothing else that did this. And so they built a very strong business on that kind of like breakthrough in being able to take a workflow that worked with developers and apply it in the design world and give designers just like a huge amount of new workflow capability. You know, they could do branches, they could do merger requests, a lot of the same things that developers have used.

00:09:40 - Speaker 3: Yeah, that opens up so much more freedom. I’ve worked with designers running up against this exact same problem, probably, well, long time ago now, over 15 years ago, but it was, it was exactly this problem of there’s one blessed Photoshop file and if that gets messed up or there’s the classic version 1 version 2, version 2 final. Nightmare.

00:10:06 - Speaker 1: Final final, yeah, absolutely. I mean this is now obviated by all the web tools like a figma that, you know, are building versioning, just like a Google doc, you know, saving every stroke, but at the time when everything is desktop based, like, these are intractable problems, so it’s kind of interesting to see how The world moves into a different medium that solves it, but then introduces other problems, like now you’ve got multi-user collaboration real time, and that’s like, you know, a big headache, but also like a huge opportunity, so there’s always something fun to be worked on.

00:10:37 - Speaker 2: I believe that the developer workflow that is Encoded through Git and GitHub, which is a more asynchronous and the merger quest as a bundle and being able to look at diss.

Obviously that whole thing is way out of reach for the vast majority of people in the world.

But I do think a version of that probably can and should be part of almost every kind of creative tool, certainly for design tools, again, as you say, we do see that in the real time collab and the figmas and sketches of the world.

I think you see this, one reason why Google Docs is really popular with writers is they have a really good versioning system or good versioning relative to the writing tools still. Pretty basic compared to what developers are used to, but where you can see new changes when you come to a document, you can look at a history, and critically, you can choose which changes to merge or reject, or have a comment this thread that is based on a change, right? That’s one of the biggest, I think, powerful abstractions in the mental model for something like Git, which is based ultimately on patches, which is you can talk about a diff as its own thing separate from the resulting code. And so that results in poll requests and then essentially code reviews and discussions around that.

And I think probably most creative tools and fields could benefit from that, but the way those tools work for developers, it’s just way too heavyweight and complicated for most people.

So, stay tuned. I can switch actually has some research tracks going on this, so I hope you’ll see some essays on the topic soon.

And then I think you heard that time zones are one of the easiest and most fun things to do in programming, which is why you’ve worked on several calendar products as your own startups. Tell us a bit about that.

00:12:19 - Speaker 1: Oh yeah, my latest venture was called Eventbot, and it was a Slackbot that provided a calendar, basically behind every single Slack channel. And this is my 4th real calendar startup, and I’m just a glutton for punishment here. I think that In general, I like the calendar space because I think it’s interesting to build tools around how we use our time. Like I think if you can make that slightly optimized for people, it has a huge ripple effect.

But I do think it is a brutal industry that where businesses are, you know, sitting in a large graveyard of failed to ups, so I’m not ignorant of how crazy that world is, but it was a fun project.

I think we saw slack growing at a tremendous rate, you know, I’ve seen a lot of different approaches in the calendar world and me and my co-founder really saw like, hey, we could build this. tool that provides a really important niche within Slack, and, you know, maybe it can grow bigger than we think and we can, you know, put it into other areas, but we just sunset eventbot after 5 years of growth.

It’s been a fun ride, but I do think that the business itself wasn’t able to sustain the amount of work required to keep it going.

Like as you said, time zones are crazy. Little known fact, there are thousands of time zones, not even just the familiar ones. There are many Cities that choose not to obey daylight savings times, laws that are passed on a monthly basis that change how you have to calendar. So that part of the business is super boring and extremely frustrating for developers who have to try to keep up and make sure that they’re current.

00:13:58 - Speaker 3: I think calendaring is really interesting because there’s a built-in moat for any new business, and if you can swim across the moat and build a business, then to some extent you’re safe, but it’s so easy to just drown in the middle of the moat with all of the complexity of time zones and recurrence rules and invitations and It’s just a nightmare of Minutia that just drags you down by the heels.

00:14:33 - Speaker 2: That’s right. Well, I forgot you spent 5 years of your life working on Fantastic Cal. I did pretty successful kind of gooey calendar, so you’re very familiar with the pain there.

00:14:42 - Speaker 3: Yeah, my first startup was also a web calendar back pre-G Google calendar days, and I’ve made some pretty fantastic slash horrible decisions in learning that, just kind of walking in naively into the problem space and making choices that I instantly regret. Lots of bullet wounds and scars in that space.

00:15:06 - Speaker 1: Oh yeah, there’s lots of strange edge cases in the calendar world, you know, being able to even have a consensus of what is now, what time is today, like, these are things that when you’re talking to users across the globe that the internet affords us, have just so many edge cases that we have to deal with, but Yeah, I do agree that I think building on another person’s platform has a ton of benefits, and we used a lot of them when we were building a bot, you know, primarily distribution was huge. We were early on in this slack marketplace, and so when we were building, we were finding users coming to us, which, you know, as a business that solves a major, major problem, just getting people to care or even know you exist.

And in previous startups, you know, you have sales motions, you’ve got marketing efforts, and here you kind of at least, if you can solve that piece, you can focus more of the efforts on product, on delivering unique interesting value to customers. But like you said, there’s lots of kind of catch-22s in that bargain.

But in the beginning days for us, we found it to be extremely valuable. We started with a free product that was truly broken. Like, I was super surprised when people had used eventbot to begin with. We had a calendar product where you could create a start date and time for a meeting, but you couldn’t create an end date and time. We launched it without that feature because we were not even sure what we were building, and we got some really, really gracious folks who were like, oh, I wanted a calendar built for Slack. You should build this. And we use, you know, the community who was adopting a free broken product to help us improve it and actually put an end time, and then subsequently actually really improved the product, but it was a blessing to kind of get user traction, even at the early days.

00:16:54 - Speaker 2: And I was sorry to see it shutting down because I’d been a user earlier on, but I was impressed by your, I guess it was an email or Slack message. I can’t remember where I basically described, hey, you know, we’re sunsetting this product. Sorry about that. Here’s exactly what customers can expect, and I think how to gracefully. Set of product which you know guess what does happen in the technology industry and there’s lots of ways to do it that I think are not very conscientious of the needs and even feelings of those end users and customers and there’s ways to do it that are more graceful seems like seems like you manage the latter.

00:17:29 - Speaker 1: Yeah, no, I appreciate that. I think I’m probably like you all have been on the other end of that, where you get an email saying like, hey, this service is shutting down, and you’re kind of like, uh, like the world is worse off, and we at least wanted to make that pain a little bit less, so, you know, we started making all the features free, so people can kind of export data. We gave customers months and months of notice so that they kind of knew, but in the end, You know, we realize that we’re stewards of other people’s data, right? And so if we’re going to be cutting our service, then we don’t want people to feel like, hey, I made this investment and now I don’t have my information anymore.

00:18:04 - Speaker 2: And on top of everything we talked about, somehow you managed to be a teacher inside of all of this. I don’t know where you find the time.

00:18:12 - Speaker 1: Yeah, neither do I, actually, it’s kind of funny.

Teaching is something I stumbled into 2012.

Actually, while I was building a different calendar startup called Calico, way back in the day, I ran out of money, and I started to, you know, think about what I could teach, and I just graduated Berkeley’s grad school, so I was like, well, you know, let me go back and Try to teach something I know, which was, I just learned how to code, so I taught an intro to code course. And, you know, at the time, intro to coding and boot camps were like all the rage, so it was a pretty well received course. So I’ve now taught two courses at Berkeley for 10 years. I’ve taught an intro to code course for non-technical people. Which is really like a primer into how not to sound stupid in front of developers.

00:19:02 - Speaker 2: I think that’s the, that’s the primary reason I think people take my course, that is to say, people that want to, they work with technical people adjacent to them, maybe similar to like a sales role, for example, and they want to be able to speak the language and interact and kind of reason better about that, not necessarily get a career as a software developer themselves.

00:19:20 - Speaker 1: 100%, yeah. I think the largest percentage of people who take the course are people who want to transition into product management, and they’re working, you know, day to day with engineers and they want to understand real life expectations, like, how does this code work and what are the restraints and constraints that I have on my job.

It’s a super useful course that we’ve got fine tuned to make it be very practical, which is not often the case for courses in academic institutions, but, you know, we we try pretty hard.

And then the second course I teach is sales for startups, where, you know, I believe that sales is just an incredibly powerful skill, whether you are, you know, at the startup phase and a founder trying to sell people on the company, on the vision, and, you know, the funding, or you’re selling to customers and trying to get them to make a purchase, so.

The two courses I teach are really intended for folks to have an ability to do something in the startup world.

You’re either building something or you are selling something.

But if you wanted to join a startup, I’m hoping that, you know, you take some of these courses and you feel like, hey, I can join this world of startups, I don’t need to necessarily go to a big company and try to like find a niche.

So yeah, it’s been fun. I definitely enjoy it.

There’s a long story of like how I feel teaching, especially these past few years where it’s been, you know, much harder, remote. I think every semester we’ve had a fire, an active shooter, smoke, virus pandemic, like, it’s been a crazy past 5 years, but in general it it gives me a lot of joy. I think something that I don’t think I can replace anymore in my life. It’s a really fun thing I get to do.

00:21:00 - Speaker 3: I think those are really interesting courses because you’re teaching kind of each side of the company about the other side of the company. You’re teaching the non-technical folk. Here’s kind of the problems and the struggles that they have, and here’s how that side of the technical people function, and then also helping teach the technical people. By the way, this is what sales looks like. This is why the other side of the company is a lot harder than just Sitting behind a desk and telling you what to do with a product sheet and timeline.

00:21:27 - Speaker 1: Yeah, I agree. I think it gives the other side a little bit more respect for these roles and what they do and what they bring to the companies. It’s also a lot of fun to teach.

00:21:36 - Speaker 3: Building that empathy within a team, I think is so important when you have an extremely small team in a startup, so that everyone knows the importance of everyone else’s role and responsibility, and you end up, I think, just so much more efficient than a brilliant engineer who doesn’t understand sales and customer needs, or someone who’s really in touch with the customer, but has no idea how long it takes to build particular features.

00:22:03 - Speaker 1: Yeah, I think it creates better entrepreneurs as well.

Once you start to realize, like, hey, if I have to look at this idea through the sales lens before I start, like, is this a good idea? Does this have legs, you know, on the technical side, on the business side, channel, marketing, like all of those things are really great to think through early on. So hopefully I catch people while they’re still, you know, in school and kind of incubating things. And I’ve gotten really great letter, you know, this is off topic a bit, but I continued to teach now for a decade because I get these incredible emails where they’re like, 5 years later, someone will be like, hey, I just realized that like, I learned this thing that I’m using, like, in my job. I learned it in your class, like, awesome job, thanks for, you know, helping me out, or I’ll get people being like, I have an interview next week at this company, like, I think I know what these depth tools means, but like, can we chat about it? And I’m like, this is amazing, this is a different level of impact. So it gives you a lot of satisfaction on a long term basis.

00:22:58 - Speaker 3: Yeah, that’s really rewarding.

00:23:01 - Speaker 2: So our topic today is building on platforms, and especially building a business on a platform.

And we have some interesting collective experience here in this group, Joe, you’ve been on the kind of platform provider side at GitHub, you’ve been on the platform, let’s say, consumer or developer side at Eventpot or building on the Slack platform. Obviously, Wulf, you’ve been on the various Apple platforms in different forms for a decade, more than that. So, I thought it would be a good chance to compare some war stories here and understand better what it means, what sort of trade-offs you’re making when you do build for a platform. But as always, I like to start with a definitions, I’d love to hear from you, Joe, and then maybe from you, Wulf, when you think platform, what does that mean to you? What are some that you think of as maybe good or bad examples, and what does that mean for a business?

00:23:54 - Speaker 3: When I think of platform, I think of A company with existing customers that wants to let other companies have access to those customers. And somehow takes money from both sides. And so it it ends up being most good for the platform provider. And then secondarily good for the companies that get access to those customers.

00:24:21 - Speaker 1: Yeah, I think that the customer focal point, I think it’s probably the best starting point because, you know, whether it’s a product or some sort of just customer relationship, that’s the value that they can bring to other ecosystem partners who want to see an opportunity, and I’ve talked to a lot of larger companies that are considering just creating an API itself, like that is a starting point.

And part of the reason they do it is, you know, a product can only fill maybe 80 85% of any customer’s needs, but there’s always gonna be those edge case requirements that might not be in the company’s best interest to build, but you still want your customers to be happy. And so I think an ecosystem provides the ability to have happier customers while maybe ceding some part of the pie or the product portfolio to a third party.

00:25:11 - Speaker 3: Yeah, and ironically I think in seeing that to a third party, you almost Entrench yourself to your customers, because now the customers to leave your platform have to leave not only you, but also all of these other extra companies that are building on your platform. So it’s a lot more difficult for me to walk away from Google, because Google is everywhere and everything integrates with Google. Yeah. And similarly for Apple, it’s really hard to leave Apple because of the iPhone and the Mac, and the App Store, and the TV and the, you know, etc. etc.

00:25:44 - Speaker 1: Yeah, it really creates a second network effect, in addition to whatever product, you know, pull you have primarily, it adds an entirely different layer of, you know, wanting to stay, and, you know, there’s lots of times where maybe the primary product is, you know, maybe lacking, but the ecosystem is super strong, and so it keeps people engaged and helps people really feel like, oh, I can’t leave, where else can I get these very customized ecosystem tools, and it’s hard to build. Once it’s built, it’s a machine.

00:26:14 - Speaker 2: The platform play is one that, you know, investors love as a holy grail of money printing machine, you know, Microsoft in their glory days, the Windows glory days was probably one of the most prime examples of this, maybe even to your point, Wulf, where it’s not necessarily that people loved Windows, the operating system, or would have chosen that above other choices available in the market.

It’s just when all the programs you need run on it, of course.

You’re gonna use that, and then, of course, that’s also a nice circular thing where if you’re a developer, you, of course, want to build for where your customers are. And when I think of platforms, obviously operating systems like Windows, iOS, Mac come to mind. The web is sort of a more open, loose collection of technologies that does represent a platform. And then maybe some more recent examples that are maybe more specialized might be something like Shopify or WordPress, right? Building a WordPress plugin or building a Shopify app, there’s actually quite a lot of possibility there, especially for a small developer within that ecosystem, and you can find customers that you would not be able to find if you were building something standalone.

00:27:22 - Speaker 3: Almost makes me think there’s a Maybe a gradient between an application that has plug-ins and a platform that has apps like WordPress is an interesting example where it is a platform, but it’s also just an app that I can install on a server and kind of do my own thing with.

00:27:41 - Speaker 1: I think you are onto something where there is a spectrum of how the integration happens, you know, there’s platforms where you don’t need to even know who’s using the platform. It’s just you provide the surface area and other people can build on top, or there’s something that’s deeply integrated where it’s like, you know, in the user interface. We saw this at GitHub where we had a lot of people who used Chrome extensions that like injected UI into the screen and It was weird for us to consider, like, are they plug-in partners because they don’t really talk to us, but they are in our customers' eyes, so we have to care about that, but I do agree there is a spectrum there.

00:28:20 - Speaker 2: Well maybe that’s a good chance for some storytelling here. So yeah, GitHub, you helped build out the marketplace. What was the drive for that and what was that experience like? What did you learn on the platform creator side of the equation, I guess.

00:28:33 - Speaker 1: Yeah, so the GitHub Marketplace was a multi-year kind of dream of mine, and uh to be honest, I think it’s because working at GitHub made you really see how undervalued, underestimated developer tools were as a broader category, and this is 2010.

In terms of context. So we saw that people were using developer tools like GitHub, but we knew that we were going to be a best of breed company. We were going against the like single suite approaches.

And so, to really shine in a best of breed, you need a lot of breed, like you need a lot of people.

You want to let a 1 1000 flowers bloom in that space.

And devtools were a difficult thing to grow. And so, in general, they get a marketplace was kind of like a long term intention of how do we grow the DevTools space with the position and kind of responsibility that we have as being on the version control side, which is a very base layer for a lot of developer tools. So we were building a platform that really intended to help developer tools blossom.

And take away, you know, some of the parts that they really didn’t want to do, which was sales and marketing.

So, we can definitely talk a little bit more about how that happened. It took a couple of years internally to get some buy-in and then externally to build the trust, but it was a really fun project which now, you know, get up marketplace is thriving and booming, so I look back pretty fondly as like, ah, cool, we helped do that. That’s a pretty nice feeling.

00:30:07 - Speaker 3: Yeah, one thing I’m really curious about is That step from 0 people on the marketplace to 1 person on the marketplace, right? Just getting that very first use case and that very first business to buy in and get going, to start things off. What was that like and what was the process to kind of maybe find that business or make sure that you had enough there for them to integrate with? What was the minimum viable product, so to speak, of A platform.

00:30:40 - Speaker 1: Yeah, I think that’s a really good question because we started by having an API that people were already using, so people were able to get information in and out of the GitHub system. It wasn’t super well loved in terms of resources, but we had people using it, and there were businesses that were created, they were just very, very small.

And so that the primary example when people think about the GetUp ecosystem is a CI tool, a continuous integration tool like Travis or Circle.

And for folks who are not familiar with what CI tools do, they basically do a check on your code. So they are looking at your code to see if there’s any errors, does it pass the test that your own developers have written, and it just gives you back like a hey, pass or fail. And so those tools existed in the market and used our API, but they were basically totally separate entities. People would come to GitHub, buy GitHub subscription. Use it, and then go to these independent websites directly, you know, find them, hope, and look for a logo that said, hey, integrates with GitHub, and be like, OK, great, like, maybe I can also use this in addition to my version control software. And so, my first V1 was really to create something very lightweight. At GitHub that allowed some traction and kind of proof of value to exist, to kind of build towards this marketplace ideal. And so our V1 was really simple and it’s kind of embarrassing, but we just did a simple static page. It was like GitHub.com/sh apps or app directory. There was a bunch of users who had apps, so we had to change the URL, but the original static web page was just a single page where we just hot linked out to every single tool that we knew that was reputable enough to be recommended, but also integrated with GitHub directly. And it was an important first step that I kind of didn’t really appreciate at the time. It was just mostly like, hey, how do I make progress? Well, this seems like a good way. But it accomplished two big things. One, it gave direct traffic to these providers. So, you know, Travis CI, Circle CI are common ones. They were starting to get a lot of traffic. You know, GitHub at the time was a top 10 website in the world by traffic. And so us redirecting even. In a small sliver was able to give them, it’s a huge boost for devs who, you know, are looking for CI tools. They’re like, well, why don’t I start here at this GitHub app page and then go out. So we were getting a lot of goodwill by those companies who are getting free traffic and likely, you know, a lot more revenue from it. But it also served the purpose internally, where we had, you know, lots of management to convinced that it’s worth building a bigger marketplace, because now we can see how many people click through. We actually requested from the folks who are on that static page, like, hey, could you send us a report at the end of the year on like, how many people bought subscriptions through you? We’d love to know cause we’re gonna put in a referral link, so we wanna know how much it converts. So it was twofold. It was really helpful from the inside to kind of validate like, will people click, like, and if so, which partners will they click on, like which ones do they not care about? And on the external side, we gave people almost a full year where, you know, we just drove traffic. It was also just a really good time. Once you start driving traffic to people, then they start wanting to talk to you more. They’re like, hey, can we be higher up on this marketplace, and what are the rules and what can we do to help? Do you guys talk to your sales teams about us? I guess that’s a third benefit I kind of failed to mention is our sales teams loved it. They used it in like every sales pitch. They pull up the page and they’d say, hey, listen, you’re not just buying a single best of breed tool, you’re buying into a network of tools. And showing them this kind of wide world that existed. So, it was a good use case for a lot of people and really low lift. We’re talking just a flat HTML page with some links and icons, so it was great.

00:34:36 - Speaker 2: Yeah, that points to one of the first big benefits that comes to mind for me with building on a platform, and that’s distribution.

And that could come in the form of direct traffic driving, but it could also come in the form of, I don’t know, you’re making a plugin or an extension to a thing the customer already knows and you benefit from the fact that they’re already a user or a customer of X where X is GitHub, and so you say, OK, so this works with a product I’m already using, and so it’s easier for me to imagine how that plugin or app or integration fits into my life. So, just by itself, you’re already benefiting from that, but then there’s the additional huge distribution benefit of having some kind of a marketplace or an app store, even this static site you mentioned, where you have really direct distribution channel right out of the box.

00:35:26 - Speaker 3: That story is really a perfect summary of how I think about two-sided markets and platforms like that, where GitHub was already extremely valuable to the developer, just as source code repository. But then adding in those extra partners, it becomes exponentially more valuable for those developers and exponentially more valuable for those partners, where it’s really a multiplying effect. When you bring in those extra companies, those third parties, make it so much more valuable than just the product alone, and it’s even much more valuable than me going to GitHub and then me going to Travis, but having that integration makes both of those. More than twice as valuable when they actually integrate and talk to each other.

00:36:15 - Speaker 1: Yeah, it was definitely good timing for the developers themselves. We had a lot of devs come to us, run these big, you know, annual conferences that could have at the time. They’d say, hey, like, I want to build this business, but like, nobody in our team wants to do sales. We’re like, OK, we totally understand that. Like, we as a company of dev tools, like, as developers, we understand not Wanting to take care of this business, let us help you with that piece, and at least make that a lot easier. And then you focus on building the best developer tool and trying out something. So, I do think that you’re right. It helps multiply efforts. And then if you have an app store, it attracts more people to want to start a developer tool or at the time, you know, a plug-in. And so it creates a bit of a flywheel in terms of creating more people in the ecosystem, which attracts more people to the ecosystem and really. Making the whole better bit stronger.

00:37:09 - Speaker 2: And maybe if I can offer a similar origin story from my own experience, maybe just a few years before you were working on the GitHub Marketplace there, Joe, I was working on the Hiroku add-on system.

Oh yeah. And this is basically a way that you can, yeah, you have the same storefront, you can provision services of different kinds, databases, logging and things people need for their apps through this little store. And the way we bootstrapped that was, we went out and did well business development.

One of my colleagues did a great job identifying some three really good examples of this would be an incredibly useful service, and it shows the kind of shape of Of the overall add-on system we would picture, and one of those was New Relic, which is analytics, one of them was SendGrid, which helps you send emails, both things that a lot of apps need, and the third one’s actually escaping me right now, but it was like a good sampling.

And we worked with them directly to do the integration. We didn’t have any kind of provider API we just kind of sat down with our developers and figured out how to plug it together, and from that, that served two purposes. One, we could see some patterns on what we should actually do in terms of making the API for more broad use, but second, now getting new people on board, we can point to the.

Businesses that were already reasonably successful in their own right, people could picture other developers or businesses could picture, oh yeah, I can see why Sendrid and Hiroku or a new relic and Hiroku working together.

That’s exactly as you said, Wulf, greater than the sum of its parts saying I want in on that, and then that’s the bootstrapping point and you go forward from there.

00:38:43 - Speaker 1: Oh yeah, Kauna’s add-ons were a big inspiration for what we were doing at GetUp, to be honest. I think we saw the ability for customers to like point click, and then add things to their bill that, you know, wasn’t previously there, but went through a different, you know, procurement model and added on to an existing subscription, like that was just a beautiful. Way to integrate that on a sales side but also on a technical ability just to know like, hey, these things are all gonna work together. I don’t have to worry about compatibility and stitching versions together. It was really nice.

00:39:19 - Speaker 2: Yeah, it’s great to hear.

Now that probably does also point to one of the risks or downsides of being on a platform, which is potentially the platform owner owning the customer relationship, which there’s a lot of value in that, whether that’s the billing or just the sense of the trust kind of goes there, you know, maybe.

Amazon for its third party sellers is a good example. When you buy something from Amazon, you’re really trusting Amazon and you’re paying Amazon and you think of them as the provider even though maybe the vast majority of stuff on Amazon’s site actually comes from third party sellers.

And so overall, you have a power dynamic between the people making the platform and the individual developers that is pretty asymmetric, and there’s certainly a lot of historical examples in the tech industry, I think of Facebook and Zynga as being a pretty famous one, but also Twitter, they at one point early on were more of a platform thing.

They had an API and building Twitter bots and Twitter clients and things, and at some point they decided, you know, we actually don’t really want to be a platform, we want more control. We want to be a product, we want more control over the end user experience. They bought Tweety, which is one of the bigger clients, and they basically overnight essentially made their API not very valuable, and they’re explicitly telling their business partners to go take a hike.

00:40:37 - Speaker 3: The risk of being on someone else’s platform should not be downplayed, because Whoever is running the platform has a favorite, and their favorite is very likely their own customers.

And so if their customers in that business model need to take a left turn or right turn, they’re gonna do that.

They’re not gonna consult you.

And so it’s very easy to be building on a platform and then suddenly realize that you’ve been left in the dust, either explicitly cut out like as in the case of Twitter. Or there’s uncountable numbers of Apple Sherlocking other apps and kind of saying thank you, that’s a great idea. I will build that instead and taking all of the market share for themselves for particularly successful apps.

00:41:27 - Speaker 2: And I think it is tough for platform creators because they do have to balance things that can and should be platform features that are built in first class things because they’re useful to everyone and so forth versus things that are in that extended.

Ecosystem. The term Sherlock, of course, is interesting because that was basically a search app, I think, for Mac, and at one point, Apple comes along with Spotlight and makes it so that that app is now sort of a feature of the platform.

And I think sometimes that sort of thing can be overrated, that, you know, the built-in feature in a platform can be kind of like a really simple stripped down version. And then you can, an app that does a similar thing, but a much more sophisticated version or targets a different audience or something like that, there’s still possibility there.

But you’re basically always at risk for that. Yeah. Joe working on GitHub, did you have any places where you had to balance that, like, gosh, this should really be kind of a feature of the platform, but we actually we have this pretty important developer and we don’t wanna screw them over.

00:42:31 - Speaker 1: Oh yeah, yeah, I think every platform. Kind of has this tipping point where you start to see like, hey, this feature, this product is getting a lot of traction, and people building on any platform should realize they are doing R&D for the primary platform at all times. Every feature you release, every experience you have is an opportunity for the original platform to be like, hey, that’s a great idea.

And yeah, GitHub we had this exact same thing where We were just a year into creating our app directories, so we got a lot of internal buy-in around, hey, this ecosystem is important, but we noticed that issues, GitHub issues specifically was a feature that was left behind in a lot of the development we did on the platform, so it hadn’t gotten a lot of upgrades it needed, and specifically, there is a way to view issues in a combo board that people really wanted and were flocking to these external providers.

I mentioned some of the providers were plug-ins. These plug-ins were Chrome extensions that injected information onto the screens, and we had lots of big customers say like, hey, we love this feature, but we can’t have people injecting into our employees’ browsers. Like, that is dangerous, and we don’t want to continue doing it. So we want you to build it. And so that was one of those moments where GitHub realized like, hey, we’re gonna have to build something in this space, it’s hugely important to all of our customers. And I’d like to say that we did a great job, but I’d truthfully say we did an OK job of letting our ecosystem partners know that this was coming. Basically, when it was halfway realized on an engineering front, we reached out to that team and said, listen, I’m just telling you now, we’re going down this path, we’re gonna build something. And of course it wasn’t the months of advance notice that they would like, but it was at least some heads up. And I think this is part of what The responsibility is for platforms that are trying to really encourage growth, is that you kind of have to take communications and transparency as a really important value. So for us that meant just telling them this existed, this is the feature set, because it allows ecosystem partners. To adjust. It doesn’t have to be the death of their business, and in in our case it wasn’t. The ecosystem partner that we told was like, OK, thanks, we’re gonna create communications just for this new release, so that we can talk to our customers and say, listen, this is a good thing, we’re happy. And it allows them to adjust their roadmap. Now if they’re gonna make more investments for the next couple of months or years, they can now say, hey, this base product might be taken, but what advanced features can we do? And that’s exactly what this provider did. They created a ton of new