Transcript

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 premium features that we knew we were never going to build. Like that was a full-on project management suite, and we couldn’t, I didn’t want to build that. We just needed to have some of the visualization stuff taken care of. So they created a fully thriving business, they ended up getting acquired down the road, but that heads up has a lot of value in terms of just goodwill, honesty, and then just better investment and resource allocation.

00:45:43 - Speaker 3: Makes me think that, especially early on in a platform’s lifetime. A lot of the Businesses and players on that platform are not necessarily building businesses, they’re building features. And so then it’s easy for them to get kind of obliterated by the platform maturing and implementing those features, as opposed to what you just described where it was someone who had a business. They were project management business, and they happened to also implement this feature. And so when GitHub kind of pulled the rug out and stole that feature from them, Well, they still had a viable business and so that, yes, of course, things changed. But they were able to continue adding value on top of the platform.

00:46:28 - Speaker 1: Yeah, and I’d say for us, those early days when we were trying to create this ecosystem and eventually the marketplace, a lot of it is rides on goodwill and people seeing that you can create a business, that it won’t just be, you know, outsourced R&D that just gets gobbled up.

So having some kind of shining lights and Good examples where like, hey, we did something that was in our ecosystem, but also that provider is saying good things about us, like, that’s a really strong signal that makes people feel like, oh, I can spend the time and build something on this.

So in the early days, transparency is so critical, and I will say the other thing we did was, we were really human about it, so we started doing these in-person meetups with our ecosystems.

So we got to know them personally, they got to know each other, so that kind of glue was really helpful when we were doing something like this, cause they knew us as people, not just like the other end of an email address, so I think Also, you know, as many other things comes down to like human relations, and I think this is just a piece of that. I’ve been on the other side, you know, on the slack side, and maybe it hasn’t gone as well, but there’s definitely moments where that human side is just critical.

00:47:41 - Speaker 2: Well, maybe that’s a good transition to talking about event pot and your experience building on the Slack platform.

So Slack’s a good example of something that was an incredibly successful product. It had reached kind of market saturation, even certainly among certain kinds of power user and technically oriented Silicon Valley teams, and they came along with not just an API but a marketplace and a way to essentially build a pretty full featured app on that platform.

Did you start with the idea for the business and then think maybe we should build it on this platform, or was it actually the other way around is seeing this new platform rising you saw as a business opportunity and then thought about what to build on it?

00:48:21 - Speaker 1: For us, it was definitely more seeing the platform exist and do very well, and then just having the context of having so many calendar startups, you know, behind me realize like, hey, I can put these two things together and maybe create something unique here.

There’s always these moments where I would go home for like Christmas. I’m from the East Coast, I’m originally from New York, but I’d go home for Christmas and be like, oh man, I’m like in slack all day, and like, you know, people my age working at other companies would be like, what’s slack? I’d be like, wow, the difference between me in the valley and like people in slack overload between like 10 different slack workspaces and then coming to the east coast and having to explain what it is.

I was like, wow, there’s still a lot of opportunity left here.

So I think that was a good prompt for like, hm, if we’re gonna build a business, this might be a good place to go. And so that we started down that path and realized this was an area that was overlooked and highly, highly valuable.

At the time there was like some basic integrations for calendars that Slack themselves had built. This was an interesting tactic as well. They were seeding their own ecosystem by creating their own plug-ins, so they created a plug-in for Outlook and a really bad plug-in for Google Calendar, among many other tools that they built for, but they did these things as a way to Cover the kind of product needs that their customers would have until the third party themselves built that tool, and I think that was a really interesting thing to see.

I also had a lot of, to be honest, a lot of GitHub employees went to Slack, and so they would be like, hey, like this is going really well, this business is is booming, and so that’s not gonna say that that didn’t affect a little bit of my, you know, choice of where to build.

00:50:05 - Speaker 2: On the point of a platform creator making their own apps.

Obviously Apple does that, Microsoft does that, game consoles do that, but we did a bit of that at Eroku, and it was partially the seating, as you said, where we would see there was just something needed, that was pretty foundational, and in some cases we would go find entrepreneurs we who that we thought would be qualified and essentially talk them into to start. maybe the first Redd add on was kind of done that way, but in many cases we would build ourselves, but trying to use the discipline of we don’t get any privileged access, we’re working through the same API as everyone else, that team is a The business unit would be a strong way to put it, but we kind of try to envision them as a little in-house company that is on the platform and then learn from that.

What are the frustrations, what are the pain points, what are the ways that this is not a good experience for the developer.

So, in doing so, we serve both those purposes, kind of plugging a hole, but also dog fooding our own platform.

00:51:05 - Speaker 1: Yeah, absolutely. I know that on the slack team they did this where they built the calendar integrations and then regularly sent usage reports to those companies being like, here’s how many people are using it, like, is this worth it now? Is it worth it now? And I think, you know, eventually it works, but it takes a while sometimes.

00:51:23 - Speaker 2: Now you spoke about trying to be a good communicator and be human and all that sort of thing and when you were on the platform creator side of the equation, being on the other side of that, how do you think Slack did or what was your experience like?

00:51:35 - Speaker 1: Yeah, I think Slack had a lot of great things that they did, and overall were very net positive as an ecosystem and platform creator. They were able to allow a lot of businesses to thrive, but I mean like all companies, it’s not all great and they had some missteps. I think for us specifically we experienced, you know, this exact kind of like encroachment into our space that every kind of platform creator.

Fears. So we were building a lot of features, especially around the Google Calendar product, and kind of unbeknownst to us, Slack had been working on their own second Google calendar integration. I think I remember this very vividly cause we actually were invited to speak at their conference. It was called Slack Connect, and I did my panel and it was great, and then later that day they unveiled this calendar integration that Really, really was a bit of a gut punch to us. I think these are times where, you know, you wish communication were a little bit more open and trust was built up, you know, we know that we are one of many. At the time there was probably 4 or 500 apps in their Slack directory. So we knew that we weren’t, you know, the only folks there, but These are the moments where having a little bit of goodwill goes a long way, cause we saw, you know, our installs dropped huge percentage, and customers were reconsidering cause they were like, well, maybe I don’t need eventbot. So it kind of put us on our heels, and it took us a very long time to readjust our roadmap to figure it out. I mean, we’re a team of two at the time, so you can imagine like, If you are changing any investment in roadmap, like, you can only do a couple of features at a time. It’s really hard to do, to be resourced and strap right there. So, it was tough. I do think Slack has gotten a lot better. Their ecosystem team has done a really great job now of literally creating a combo board of features they are building, and they’re pretty public about this, so they are at least giving folks a heads up into spaces they will go. They also do this for infrastructure, you know, hey, to be on the slack platform, you’re gonna have to have this technical back end, and so they’ve given people a lot of notice that these things are gonna change. We had an incredible experience with people finding us organically, and then being able to take that interest and create products around it. But I think it’s always been a challenge to see further than a couple of months or 6 months down in the road map, because you don’t know what Slack is gonna do. They’re under deep competition with Microsoft Teams, and so you kind of are hoping that like, hey, I hope my niche isn’t too interesting to them, that they want to take it over, but interesting enough that they think that we’re valuable and want to like help us out on the sales side. There’s a fine line there, but Overall, I think that they did a pretty good job of allowing entire businesses to form, and many of them, you know, have now been acquired and have spun out to very large things. I was just talking to the folks who ran Disco, which was acquired by CultureAmp. And then Troops, which I think was maybe the largest Salesforce add-on, got acquired by Salesforce directly. And so there have been definitely some strong successes that came out of that, and Slack was smart about it. They even had a fund, I think that’s probably one of the more unique things I saw. They created a venture fund attached to their ecosystem, so they would definitely try to be financially aligned with their ecosystem as much as they could.

00:55:04 - Speaker 3: I’m curious about your experience. Building on Slack, but also building a Google calendar. It almost strikes me as building on two platforms at once, to some degree.

One very stable, it’s been around a long time. Google Calendar is probably not gonna like shift underneath you.

But do you see that being very common? Maybe in the GitHub world as well, or in other interactions you had with creators on Slack where they had feet in multiple platforms, and if any one of them changed. Then they were in a tough spot. Does that increase the risk, or do you think in that case, well, Google Calendar is stable enough, it really didn’t increase your risk. The momentum of slack and the dynamic nature of that platform is really where all the risk was anyway.

00:55:49 - Speaker 1: Oh no, I think you’re right, it dramatically increases the risk.

You’re, you know, toxing your ability to keep up and even just to do maintenance and keep it running, like you have lots of risk of it blowing up from either side of the connection.

I will say that it’s actually pretty common in a lot of the bigger ecosystems to have these kind of two-sided integrations.

They’re essentially just like really beefed up zappier plug-ins, like this could be, you know, something you could automate, but like, here’s a tool that does it.

We actually took out a lot of that risk, because what we did is we integrated with Slack directly via their API.

But then when we integrated with every other calendar, we used the dot ICS kind of Cal format, which is an international standard that almost every calendar can integrate with.

So we kind of intentionally didn’t go the even deeper route with Google Calendar, knowing that it was going to be much more difficult to like maintain and increase, and customers every year would give us these like top requests, and that was probably one of their biggest requests is I want it auto populating.

Instead of like, hey, you just have to connect this ICS calendar and it’ll populate in under an hour. So we kind of took the customer dissatisfaction to give ourselves a little bit more breathing room. But yeah, it’s a really good point that those two sided integrations can be a gold mine if you find a really good niche and build it out, but it’s a risk that, you know, either side ends up saying that’s a great idea, we’re gonna do it.

00:57:20 - Speaker 2: And coming back to what I mentioned in the beginning, which is sort of the technical side of a platform to build on, and the business side, called the distribution aspect or the partnership aspect.

I’m curious for the case of building eventpot.

How much was Slack’s API and the technical infrastructure and the fact that maybe you don’t need to worry about user identity or you have a bunch of existing kind of UI concepts like channels, for example, that your users already know and you can skip forward to some unique value that you’re providing versus, you know, making basic login pages or onboarding flows, how much was the value in that versus Either one, you’re in their marketplace and people just search there and find you, or even just that they Google Slack group calendar and they find you.

00:58:08 - Speaker 1: Oh yeah, we ran a lot of those ads too, very successfully in the beginning, but the ability to not have to deal with common overhead for us was a really big boon to creating our company.

Knowing that we didn’t have to worry about maintaining user databases and Keeping track of like every workspace and all the details that essentially Slack takes care of because that’s their products, bread and butter. We could essentially use that and bootstrap off of that.

So it saved us countless hours of time, and also I think for a lot of our customers, some of them are, you know, very big businesses, they would have really deep requirements if we even wanted to build that for ourselves. So, knowing that Slack like has the resources and has the kind of edge cases filled out, great, it allows us to focus on much more.

Unique value adds on top.

And I think also channels as a concept was new to people. I mean, they understood threads of email, and then when you move to a channel-based kind of topic discussion forum, they didn’t know how to react and so it allows you to take that space where it’s not defined on what it should work like, and then add to what it could work like. As an example, a lot of people had a Happy hour type slack channel that they would just use for happy hours. And so we would say, oh, we can create a calendar behind that, and every channel gets its own calendar, so everyone can create their own events that live inside of that channel. And so we started pushing the boundaries of what people thought a channel was. It wasn’t just chat, it’s also a calendar, and we introduced a visual calendar system in our second year, where you could see a visual calendar of that channel’s activity. So people were like, oh great, every Monday morning I know exactly what’s going on for the rest of this week as it relates to this topic. So I do think that Slack’s kind of basics gave us the jumping off point to build some really cool stuff. Even if we wanted to build it, we wouldn’t have been able to recreate it, but seeing that it was there, it gave us just, you know, nice constraints to create some innovative stuff.

01:00:16 - Speaker 2: And certainly our experience on news and well you probably also can speak to this for other apps and companies you’ve been a part of, but, you know, the Apple platforms at this point, particularly the iOS, is just one of the most filled out in the world on that, you know, thousands of APIs you can use, they dictate programming language and essentially you basically have to use their IDE or or close to it. And then on the distribution side, the App Store obviously is the one place, one and only place you can get iOS apps, and there’s very tight controls there and you have a storefront there.

But yeah, that is something where I think when the App Store came along in those early developer kits related to it, you would see the cases of, I don’t know, a talented 16 year old somewhere that could Write a useful app pretty quickly, and something that adhered to the platform conventions and felt very professional, and they put it in the app store, they don’t even need to make a web page for it, they just put up some screenshots in the description, they sort of automatically get this presence and this distribution.

Maybe this comes back to where the platform as a metaphor even comes from. It’s the idea, it’s a thing you could stand on that starts you in a higher place than you would have been starting from something lower.

01:01:32 - Speaker 3: Yeah, and I think that higher place comes, like you mentioned, all the APIs and all of the foundational code that Apple provides is a really big piece of that. I think the second really big piece is trust. Everything inside of the Apple ecosystem runs inside of that sandbox and there’s kind of privacy built in, and users know that. So the harm of a bad actor is dramatically reduced, and I think that’s true of, you know, almost all successful platforms is there’s important guardrails. So if I install something on Platform X, I know that I’m only giving it permission to do A, B, and C. But the really dangerous stuff, it can’t even see, can’t even get access to.

01:02:18 - Speaker 2: So installing a Chrome extension, for example, which potentially could have access to everything you look at your banking website, all your passwords, etc. and I think the review process for most of the browser extension stuff is a lot lighter touch than than say Apple’s review, but they do have those permission systems. So I know, for example, that I have to answer that question about this can read and write data on all the websites you visit.

Do you want that? And then I can pause for a moment.

Question, do I trust this developer? How important actually is this plug into me versus something that asks for more restricted permissions.

It only is modifying data on this one site because it’s designed to be, for example, on board for GitHub issues, to take an example from earlier, and so then I can go, yeah, that’s all right with me. I’m willing to extend that level of trust to this otherwise unknown piece of software I’m downloading from the internet.

01:03:14 - Speaker 3: Yeah, and just forcing that visibility, I think is such an important piece to maintain trust, not only from the platform’s perspective, for the platform maintaining trust with their customers, but then also building on that platform, you kind of immediately gain that exact same trust that you would otherwise have to build from scratch as you’re just some random no name company trying to sell me something. Which is a lot more tenuous than, oh, yes, if I install this, I see that you get these 3 checkboxes, but not these other 3 checkboxes. Great, sure, let’s try it out, who cares? And that freedom, I think is a really important piece of that foundation that the platform can provide.

01:03:58 - Speaker 1: Yeah, that trust by proxy is something we felt exactly the same when we were building eventbot where, yeah, we have some of our like Fortune 500 customers would be like, well, you know, you seem to be a top rated app in the Slack directory and you’ve gone through their checks cause they do a review, but like, OK, they know who to call if something breaks and so I can trust you because they trust you and yeah, it’s an incredible. Ability to kind of use and not have to start from scratch, like you said.

My theory is that if you’re a first time founder, I highly suggest working on another platform, because the amount of jobs you need is lower. Like I remember for us, you know, we were two people, but we didn’t have to hire a salesperson or marketing person because we were using the app directory. We didn’t have to hire a designer, because the platform itself dictated, like, here’s what the UI elements can look like. And there wasn’t that much we could do, so we knew like, OK, we’re not gonna have to do any kind of designer hiring.

And the same thing, if you keep going down the list of things that the platform takes care of, those are literal jobs you don’t have to hire for, which lets you be smaller and try to build something unique with just the pieces you have. And I think that’s a really valuable part of Starting a company and not having to feel like the full weight of every part of the business on your shoulders, but maybe a lighter load at first to kind of get people situated. I think it’s a really great way to start as an entrepreneur.

01:05:33 - Speaker 2: That’s a great point. Those constraints could be frustrating for a more experienced set of entrepreneurs or just a bigger team or they want to hire for those roles, they want to do that bespoke design, so they’re annoyed that they’re limited what they can do, but if you’re a smaller team and or have less experience in whatever that particular space is, those constraints are basically awesome. Yeah.

01:05:58 - Speaker 1: We were terrible designers, so when we found Slack, we’re like, great, we can just put text and buttons, like, that’s all we want to know how to do.

01:06:05 - Speaker 2: Maybe on the eliminating a potential early job on the design and marketing side, one thing we’ve grappled with quite a bit on Muse is the essentially what your primary storefront or what your primary first touch point is for customers.

So, you know, we have a pretty extensive website where we try to describe the product in detail and provide videos and Linked to this podcast and all that sort of stuff. We also have our app store storefront, which is very important for a lot of reasons.

First of all, we get featured there. Secondly, people search for stuff and find us, and thirdly, in some cases, people are just used to linking to the app store, so we’ll get a mention in some article somewhere and someone will actually link to our app store entry. And for me, that’s been a challenge because we’re very limited what we can put there. They have very strict rules about what go in the screenshots, the screenshots themselves are very specific kind of sizes and ratios, the description text is basically totally unstyled and so making it kind of flow well without section headers or whatever is kind of a whole trick. You just have way, way less control. So again those limitations are great if you’re a solo founder or a smaller team, but for us who do have that kind of design and marketing capability for us, it can sometimes be a restriction, but we do really need to think hard about we have users or potential customers who will enter from either of. Use places and they need to both make a good first impression, they need to both do their best to explain what the thing is and pitch you on why you might want this. They cross link each other naturally, our website is gonna link to the download thing in the app stores as a matter of necessity, and of course the App Store as well as our app links to our website. But yeah, maintaining both isn’t awesome, but then at the same time, there is so much to be said for a more developed business having more freedom with their own web storefront. Curious, yeah, how that was for you with Eventbot or Wulf, how that’s been for you for some of your other businesses.

01:08:08 - Speaker 1: Yeah, there’s definitely been times where we wish we had more ability to customize anything.

For us in the app store, they allowed mark down but, you know, not images, and so we’d be like, OK, we can style text exactly like you mentioned earlier, like the way we want, but we have to be really thoughtful about, OK, what’s above the fold and what categories of text do we want to put in there.

I remember early on we had a couple of clones that basically were just eventbot by a different name, and they even copied our app directory description format, and we were like, wow, this is, you know, an impressive flattery and impressive determination by these cloth makers to really get every detail right.

And I think that it ended up being a way for us to say, all right, like if they’re gonna compete with that, let’s change up our very constraint driven. Marketing and do that in a slightly different way that allows us to kind of show that we are better.

So we did route people a lot to our website, we linked out to like external people who talked about our app that they couldn’t link out to and I think Slack has a really incredibly good onboarding for new users, and so we started doing the same thing, where we would onboard them on the website or the app directory wherever they were looking at us, and then have that follow all the way through the actual usage.

That was our way of trying to make the experience a little bit better and different than our clones, and then also better for our own tracking and kind of experiments that we would run ourselves.

I’m curious, were you able to do that in the Apple app store? I know that they’re notorious for locking down the differentiation in those descriptions and initial experiences.

01:09:51 - Speaker 3: Yeah, the Apple app store is interesting because they’re very restrictive on screenshots, on text and screenshots, or lack thereof, on kind of the format of the app description, which doesn’t even have a markdowns, so it’s very, very plain.

I think another interesting thing that’s restrictive on the Apple ecosystem is the business model restrictions, and that’s become better over the past number of years, but especially early on, it was, you get a price and that’s it.

And so, if you’re not free, it’s really gonna be a struggle to get downloads because they have to open their wallet before they even tried the app. And overcoming that trust to say, please give me your money, by the way, the only thing you know about me are these 3 screenshots and a paragraph, is really tough.

It’s a lot better now, I think because there’s free trials, there’s subscriptions, there’s in-app purchase, there’s more flexibility there on the business model side. But surprisingly, there’s still very little flexibility on the actual storefront, on the store page itself. I think there is some, the blessed hand coming down and anointing you from Apple. There’s some exciting pages and, you know, more features and things like that that they give to very specific partners, but for the overwhelming majority, that storefront page is the same as it was 15 years ago, which is surprising, I think in many ways.

01:11:21 - Speaker 2: I think the pricing limitations as well, which now that they have subscription pricing and in app purchases and so on is is pretty good, all things considered. It covers the common cases, but one place that interacts with the storefront that I think is a basically a bit of legacy baggage from that history is that apps like ours that have a essentially a free trial, but more of a storage limited trial. rather than a time limited trial and then it’s a subscription purchase, but it just lists as it’s a free app and then it kind of mentions, oh there’s an app purchases and if you scroll down somewhere, there’s a little, you know, divot thing you can open that it has the various plans that are available listed in really small gray text, and it also includes legacy plans that actually still have some customers on that you’ve actually sunsetted for new. Customs, but it lists those out and so it can be just that part of it, which is so important, right? Like most websites, our website, the pricing page is one of the first links. We spent a lot of time trying to explain exactly what you’re buying, what do you get for free, what do you get in the lower tier, what do you get in the higher tier, what’s the dynamics with your data, once you cancel that sort of thing. That’s just so critically important. And the ability to explain that on the app store is basically nothing, which actually results in bad reviews as well, which is people come in and expect one thing, oh, it’s a free app, I guess there’s an app purchases, I mean, I’ll be able to buy a $3 emoji sticker, and then they see it’s actually a pro. you know, prosumer subscription price and they hate subscriptions and if they had known upfront that they would probably just not install the app or not try it, which is totally fair. You want to have that information before you start, but then you feel tricked in some way, but there’s actually nothing we can do about it, that’s just how the storefront is set up.

01:13:12 - Speaker 3: Yeah, I think there’s a lot of, like you said, baggage that comes from the Apple ecosystem 15 years ago, where it was a one time purchase for $1.99 and now you have lifetime access to that app, and so it really encouraged kind of a race to the bottom on pricing, and then once subscriptions were added, once free trials were added, once there’s More ability for professional pricing, raising those expectations of price for the customer is always way harder than lowering the expectation for the price. I mean, like I said, it’s been 15 years, but I think that weight is still pulling on developers and pulling on prices from its lowest price wins legacy of 15 years ago.

01:14:00 - Speaker 2: Well, Joe, since I know you’re a teacher and you’re good at summarizing complex topics for your students, maybe for me and Wulf and for our listeners you could briefly sum up what’s the overall if you’re an entrepreneur or a software creator, how do you see the pros and cons of building on platforms?

01:14:19 - Speaker 1: Yeah, yeah, I do love to summarize. I mean, thinking about all of the aspects of platforms that we’ve kind of talked about today, there is some real truths that I think creators have to go into building on top of a platform and just be very clear eyed about those risks of, you know, either being overlapped in terms of product or being restricted in terms of pricing. And those things, some of them come, you know, with success, so they’re good problems. They’re things that happen, you know, if you are making a product that people want and are trying to really grow, and then some of them are just existential, right? Like, is this app gonna be around? Will they shut this down? Will I be able to keep a long-term business? So I think those are very real and, you know, you’ve gotta have real conviction, not just like, hey, I read a blog post and it told me that it will. So you’ve got to like do that diligence, but I think the Incredible positive attributes that come with building on a platform, you know, allow for tons of experimentation, tons of real strong businesses that could only exist in an ecosystem that’s already provided.

I think not just for full-time founders, but just for entrepreneurs who are looking to like make that dent in the universe and have it be sustainable.

Those platform businesses where you can find that exact match, is just an incredible opportunity. And it’s also just a really great experience to build businesses with another company.

There’s some part of entrepreneurship that is quite lonely, and so being a part of an ecosystem gives you a kind of like built in friend founder network where you’re all kind of go through this stuff at the same time.

So, I’m very much pro platform building as long as it’s done, you know, with clear expectations and good opportunity.

01:16:11 - Speaker 2: Well, let’s wrap it there. Thanks everyone for listening. If you have feedback, you can write us on Twitter at @museapphq and via email, hello at museapp.com. And Joe, thanks for sharing all these great stories, and I’m really curious to see what comes next in your career.

01:16:28 - Speaker 1: Absolutely. Thanks, Adam. Thanks, Wulf, it was great to chat with you all.