The Secrets of Expanding from a Single Product to a Platform Play: Loom VP, Product Anique Drumright

Hi, my name is Nique Drumright. I lead both product and design at Loom. I definitely invite you all to let us know where you are joining from. I am joining from San Francisco this morning. I have my sidekick Ollie sitting on the couch, which is my dog. Hopefully she won't bark. But we are really excited to connect this morning and I hope if you are still early morning like us, that you've had some time to grab coffee. And with that I will turn it over to Justin.

Hey, good morning, afternoon, evening folks. I'm Justin. I am calling in from Vermont where we are just starting to get to the peak of autumn fall color, which I'm very excited about. I am the group product manager for Loom's ecosystem pillar which is responsible for building out our platform and have learned a lot of the lessons. I actually joined Loom as an engineer and have now switched the product side. So it's been a really fascinating set of learnings here that I'm excited to share today. Awesome.

And Justin, as people are signing on, do you want to quickly tell us how you got the nickname vegetables?

Yes. So as I mentioned, I used to be in engineering previously at Airbnb. And at Airbnb it was extremely common for folks to have custom slack handles, especially in engineering. And one of my team members had the slack handle of beef, which is fine, but as a vegetarian, I got tired of talking to beef all day and decided, you know what, I need to take a stand. I'm going to switch to add vegetables, which I thought would just stay on slack. But then people started calling me vegetables in real life and a lot of vegetable derived nicknames like veggies, but also really going out there for things like V8 or maybe individual vegetables like carrots or celery, it really became a whole thing. And so when I joined Loom, I took it with me. And to take it with me, I needed to make it my preferred name in the HR system. So I thought, you know what, I'm going to change my Twitter handle. I'm just going to make it a brand. And so now I'm now I'm vegetables reading.

All right, with that incredible factoid, let's get started. So we have released the Loom SDK platform in the last six months. And so we are really excited to share kind of some of our hard lesson learned and also lessons we've learned from other companies that we really admire. We will begin by giving a little bit of background information on how we think about platform as well as a little bit about Loom in our journey and why we decided to expand from a B2B2C successful product to expand into a bit more of platform. In addition to continuing our end consumer product. I highly encourage everyone to chat during the session. Justin and I already spend a ton of time together, so we'd love to spend time with you and hear your commentary and your questions. We also have a Q and A functionality in Zoom, so if you have any, any, any questions, please drop them in there. And I will be staying on top of those questions throughout the session. So with that, I will turn it over to Justin.

Great. Thanks, Anique. So as we're getting started, we're talking about platforms, platform plays what is a platform? And really platforms are everywhere. If you have a SaaS product, you're built on top of platforms and you probably even have a platform yourself. It's just an internal platform. So a platform is just the foundation for creating, exposing your experience to your, to your customers and users. And platforms come in many different forms. There's APIs which are typically invoked over the web with different kinds of web APIs, whether REST or GraphQL. The protocol doesn't really matter. The key point is that you're taking core functionality of your product, of your application, and making that functionality consumable or interactable with partners and ultimately your end users. There's packages of APIs called SDKs as well. And an SDK is really just trying to make for the simplest possible implementation of a more complicated surface area, beneath, inside.

And a little bit more background to make sure that, that we're all accessing the session from the same level of information. I wanted to share a little bit about what Loom is as an end consumer product, because that is ultimately what we are building our platform off of and why our SDK has been successful. So Loom is a video messaging product for work. And what we think about every day is how can we help people at work be more effective, more effect, more efficient, and ultimately more expressive. We believe that video has an unbelievable ability to help you connect as a human and express yourself in the workplace. So I just want to quickly show you the Loom product because this is really what our partners and our end developers are embedding in their product through the SDK. So this is the core Loom video messaging product. Oh, look, even says express yourself. I didn't do that on purpose, but this is the simple recorder that Loom is based off of. And this is really how people became familiar with Loom as an end consumer. And what is being packaged now through our SDKs. So if I were to start a recording, I would simply click start a recording, talk a little bit about my screen, and almost instantaneously it would be recorded and rendered and I'd be able to grab a link and share it to Justin and share it with the group. This is really Loom. Our journey from this end consumer product to our platform began in 2016 when Joe and Vinay pivoted their original company called Open Test that was focused on user research to Loom, which is who we are today. After witnessing the power of video at work and they released the Chrome Extension. From the Chrome Extension, the product market fit of the product really accelerated and Loom recourse itself its desktop recorders and also in 2018 released its embed SDK. The best way to think about the embed SDK, if I open up Notion today, I can click a loom and I can view it and I will be able to react and leave comments as if I was in loom.com and then come 2019, where vast majority of knowledge workers transition from working in the office to working remote, we began to see a significant amount of inbound, both from developers and also from partners saying, hey, I want Loom in my product and I don't want to build video. Video is incredibly complex technology. How do I build a Loom like experience within my product without having to invest in all of that foundational technology? Fast forward in 2020, 2021, we put a lot of energy into building this and and we released the record SDK with 10 partners including Trello, Trainual and Miro. And so this is really our journey at the highest level from an end consumer product to then continuing to maintain that product while expanding into more of a platform. And over here you can see some of my favorite kind of tweets that we got as inbound, which is basically people just asking for the Loom SDK, both the embed and the record. So first one is who's making the version of Loom that I can integrate directly into my product via an API. The next one is the first thing I did when we decided we wanted to add video recording to our platform was go look to see if Loom had an SDK. So again, it's just really a great example of us partnering with the market and getting a ton of signal from the market that there was a fit and a demand for this. And so now we are done with the background kind of on what a platform is. What's Loom, what's the journey? What does the SDK experience look like? And now we really just want to share about some of the hard lessons we've learned over the last year or so. And with that, I will begin with our first learning, which is timing is incredibly important. And I think one thing that Justin can definitely attest to is when you're, you're going 0 to 1, you need absolute focus. And if you're not willing to create absolute focus, this will become a big distraction from your core product team. So we would love to turn it over to you on what you think is the biggest driver to expanding into a platform product, market, demand or capacity? I see the polls coming in. We'll keep it open for about 10 more seconds.

I have to admit, watching the results update in real time is pretty exciting. Who will win?

All right, I think we should go ahead and end this.

Great. So it looks like demand came in first here. Well, I've got great news for everyone who answered. Whether it was demand, market or capacity, you're all right. Because the fact is the timing's not right to make the plunge unless you have all three. So first, market. When you're thinking about a platform, it's a different kind of market evaluation than just your core product. You need to be thinking about the degree to which this platform play is going to be able to scale from both a business and a product perspective. So for us, as an example, we're talking about video. And Ben Evans noted that video is in the process of going into everything. Video will just be a part of all products at some point. And so the market here is as large as the Internet is. This is truly a web scale market. When you think about something like marketplaces and Stripe, which is a very well known and established platform. But they didn't start with a marketplace solution. They ended up adding a marketplace solution after establishing some core financial products as platforms. And again, marketplaces as a concept are massive. Everything can be a marketplace. So when you're thinking about these kinds of markets, you're thinking about things that have Internet scale opportunities. And this is for the business, but it's also for the product opportunity. Because you're going to need to be building something that is not just for end users. It has to be big enough for there to be a community of partners and developers who are building on top of your platform. And so there has to be enough space for all of them to be operating and being successful within this market. And that connects really well with demand. So our partners already asking for this kind of platform based functionality and perhaps even more importantly, our customers asking for it. Because even when you're building a platform, who your customer is doesn't change. End users remain your customers. And yes, they might be interacting with your functionality via a platform, via a partner, but you still need to be prioritizing their engagement, their happiness. Because if customers aren't happy, your platform partners won't be happy either. And so you need to make sure that you have demand on both the partner side and the customer side. And we're going to be talking a little bit more about the partner side in a couple of slides. The final point I want to make here is capacity for us with our platform. We wanted to be investing in it much earlier than we ended up actually making the investment. And with the move to remote in early 2020, with the pandemic, that was a key driver in LOOM growth, which at first sounds like it would be a good thing for Loom, but it also came with some very significant scaling challenges when you can imagine the number of people going to try out loom all at once. Definitely made more than one database crisis. We needed to delay investment to actually be at a point where we could justify building an SDK, building a platform. And so you have to be really careful because you want it to be painful, you want it to be so early that it costs you, because if you wait until it's cost free, you've waited too long. But you also don't want to make the move so early that you're significantly slowing down your core product. So it's definitely a balancing act. And you can probably never even across all of these, you'll probably never get the timing exactly right. There's. You will almost always be a little too early or a little too late, but that's okay. You just need to make sure that you're keeping all of these factors in mind. So now you've made the decision to go in, you're going to build a platform. And now that you've made that decision, you have to really go all in on this. This is not something that you can dip your toe into. You should be trying to make a big splash with this effort. And one of the key things here is that this is a product like any other. And like any other product, discovery is a core part of the process. So you're going to start like with any other product, by talking to potential customers. Now, with customers that you're going to be talking to are a little bit different because it's not just your end users it's also the people like Anique mentioned who have reached out to you on social or through partnership channels or what have you saying, hey, I really want to build on top of your product. I really want to have your product functionality in my product. Let's see what we can do here. And so you're going to take that just like with anything else and have interviews and try to identify a key area of focus. And I think this can be something that is an anti pattern with platform plays where people think that they need to build Stripe in the first go and they don't. You need to have something that's definitely a minimum lovable product here because you already have a core product that you don't want to damage in any way. And because it's a platform play, the costs of poor quality or mistakes are higher than normal. It takes longer to recover from them. But at the same time you want to make sure that you're solving for a really core universal use case and then you will learn from that and expand from that. And on the point of learning, you want to make sure that you have at least one and ideally two to three key partners who are so excited for this that they want to be co builders. So they're going to be giving you feedback throughout the build cycle. They're going to be the first wave of integrators actually building on top of your platform functionality and they're also going to be co marketers with you when you start to bring this into the market. They will be there to share their success as a use case and to amplify the messaging and your go to market strategy.

And Justin shared a little bit about kind of going zero to one with partners. I also think there is in going to 0 to 1. The other side of it is to think about who the team is that is really building this product. I think I shared this earlier but you absolutely need a product design engineering team that is only focused on getting, getting it zero to one. They are not maintaining the existing business. They are laser focused on getting your platform to market. I think the other like key ingredients that's flexible, that's, sorry, critical in terms of who needs to build this product with you. You want them to be flexible and you want them to be iterative because to Justin's point, right, you're building this with partners and you want someone who has an iterative approach that wants to get in there with partners and making sure that we are absolutely building the right thing. I think in terms of who the product manager is on this product. Ideally they have two superpowers, they are technical. So the reasons why Justin moved from engineering over to product is we actually really needed someone who was a creative problem solver, both from a business perspective and technically to be leading this platform effort. And then I think the second key ingredient is great at partnerships. Right. The traditional product manager loves working with engineers, designers and end customers. But when you're building a platform like there's, there's additional, there's additional stakeholders. Do you like interacting with BD? Do you like working with other CEOs, other product managers that don't work at your company? Developers, engineers? The number of stakeholders in complexity just increases. And then I think one of our hard lessons learned is we were really focused and obsessed with building a singular product team that was only building 0 to 1. And we should have done the exact same thing on the product marketing, go to market side side of assembling like a truly a team that was cross functional and ready to build a startup within a startup. All right, and speaking of a teams we would love to hear about before we kind of get into the people that we learned from as we were building this product, we'd love to hear from you all what are some of the world class platforms that you have seen and you have really looked up to and respected. So if you want to kind of throw in some, some companies in chat, we would love to hear who you all are looking up. All right, Justin, I will turn it over to you.

Great. Thanks Anique. And people can feel free to keep adding some examples here. We see some great ones. But one of the hard lessons here is the importance of self service and the fact that nobody wants to talk to you. I see in the answers. We've got Stripe, we've got Twilio, and perhaps unsurprisingly of the three examples that we're going to be sharing here, that's two of them. So Stripe consistently considered one of the best platforms in the business. From the initial discovery on their marketing page, through management of any sort of implementation that you do, the entire journey is top notch, seamless and perhaps most importantly, confidence inducing. So if you're going to be building on top of a platform, you want to be fully confident that this platform is going to be reliable, that when there's bugs discovered, they will get the solutions for those bugs out quickly. You don't want to have to worry about your platform because you have enough other things to worry about. Right. And so Stripe does an excellent job of making people fully confident in in Stripe as a platform before they start building. Twilio is a very similar thing. They are well known for having started with a real developer first orientation, the famous talk to your developer billboard sign campaign. And their entire experience is very much based around this idea of tight integration in marketing documentation and code. So it's very clear as you're working through Twilio and you're getting started and you're experimenting with Twilio, you don't have to actually talk to Twilio to do very much. You can actually just spin up a product on their platform without needing to go through a conversational cycle. And Stytch is a brand new player, so it demonstrates that you don't have to be a very established company being around for a decade to do some of these things. Stytch actually started in 2020. The co founders were xplan, which is another fantastic example of a platform. But Stytch is an authentication platform. And what they do really uniquely is that in their documentation, they start with templates in real examples before actually getting to the APIs themselves, so that it's really easy to learn how to use their products before you invest a huge amount of time. And that balance of learning without investing time is the key thing here, and it's why no one wants to talk with you. So for a platform operational, the operational cost is actually quite high on your end. So you need to ensure that there's strong documentation. You need to teach partners what the use cases are. So products, potential products, managers who are interested in building on top of your platform want to know, how do I integrate this? What are the use cases? Business stakeholders want to understand what's going to be the ramifications on their KPIs. Engineers want to know how hard is this going to be to build against what are the capabilities? How can I innovate with this? And if you need to be involved in all of those conversations, it's going to crush you operationally because again, you're starting your platform with ideally a tight tactical team. And if that team is spending an increasing amount of time on operational concerns instead of building the actual platform, you're not going to get enough speed to actually kick off that platform flywheel. So ensuring that your platform is as self serve and well documented and frictionless as possible not only is going to encourage partners to build on top of your platform because they're able to experiment, it's going to free up your team's capacity to focus on building out new platform capabilities. And the final thing to note Here across all of those partner or all of those platform examples, quality has to be built in from the beginning because the cost of a bug is just significantly higher in a platform play. You may need to go through an upgrade cycle through one or more degrees of partners in order to get a fix out there. So you have to think from the beginning how do we build quality from documentation to implementation to observability across the board.

So summing it all up and then we will get to Q and A if we could go back in time to sum up our hard lesson learns. I think one thing to definitely anticipate is that partnerships discussions are lengthy and I think one of the smartest things we did from a go to market perspective was we focused on really critical partners and getting those successful and just know that it is going to be a bit lengthy. The second major learning if we could go back in time is carve out go to market resources in addition to your R and D resources because this is a totally new motion for your company as you expand from B2C to B2C plus platform. And then I think the other major thing that I would say is just lean into your beta community, not away. It may feel a little messy, it may feel a little overwhelming with so many people in your Slack instance etc. But these are your co builders and you want to hold that community really tight. All right, so enough from us. We would love to get to a few of the Q and A that we that we got in. So Justin, I will let you start off. How did you go about building a case to convince the C suite to build an API SDK?

That's a good question. In our case it's a little bit unique because I think our CTO Vinay was perhaps actually advocating for this even before we were ready to build it. So it might have been a little bit of an inverse situation to say actually we're not quite ready yet to build an API or SDK as opposed to building a case to convince in the other direction. It's the same as with anything else. You want to have data backing up your argument here. So this gets back to the fact that your platform is a product. What are the indicators and what have you found in your discovery process that indicates that you have the scale here, you have the demand here and have you right size to the investment to know that you have the capacity as well. So what's the potential return on this? How much is it going to cost you and try to be as fast with the initial build as possible. So again, on that minimal initial focused use case, you want to again get this into the market and learn and iterate, just as with any other product.

Yeah, and I'll just add my own opinion here. I think it, it goes like the beginning of our slides. It's like, what's the total addressable market and what are your signals that the market is ready for this product? If I could boil it down to just two things, Justin. This question is actually especially uniquely. You're uniquely qualified for this one. Some developers get scared at the complexity of building APIs, SDKs, especially given the uncertainty and ambiguity of unknown use cases. How did you overcome this? And I'm going to drop this in chat because it was a bit of a long question.

It's a really great question and I do think that this is universally true because there is this perception among engineers that other engineers are going to be judging their code. When you join a company as an engineer, you have to get over the fact that new engineers at your company will be evaluating what you create. But when you're putting code into the market as a platform, it feels like contributing to open source. So there's a legitimate source of concern there. I think one way that we mitigated against this was that we did have those early partnerships. And those partnerships on co building are not just on the product and business side, they're also on the engineering side. And so we were able to have slack conversations with partner engineers who were able to give us really good feedback early on before it went fully public. And so it felt much more collaborative. It felt much more like a team effort and that really helped the team. I will say that building your initial zero to one platform product is really, really hard. And one mistake I think we made was that we didn't recognize how hard a lift it was on the engine. And I think we could have done a better job of encouraging all of them to take a break and take some time off before the next sort of 1 to 10 push that will inevitably follow up on a successful 0 to 1 launch.

Yep. All right, next question. What should the self serve signup process look like specifically? When do you decide to charge versus offer it for free? And how do you make sure building on your platform has a successful and speedy launch? I'm going to take the free versus charge and then I will turn it over to you for the successful. How do you measure a successful and speedy launch? I'm going to drop this question in chat just so everyone can see it. So in terms of when to give the product for for free versus paid. I think for us at Loom, right, we have a long history of offering our product to free for users until a certain threshold in which we charge them because we're demonstrating value. And I think we've taken the exact same approach to our SDK, which is we believe that video messaging fundamentally is going to change the way people work and give employees a ton of power over their own day. And we want the ability for people to build that into their own product. So we are actually starting with a fully free product. There may be next gen generations where it's a paid SDK. We are still exploring that options, but I think for us, we really want to get our product out there and we want it to be used and we are confident that we can monetize as we create that value for our partners. Justin, I don't know if there's anything you want to add there, but then share a little bit about launch success.

The only thing I'd add in that is it's again, just like anything else. What's your go to market strategy? I think the interesting thing with the platform is that you do need to be mindful of how it relates to your overall product strategy. So your go to market involves both your core products market offering and the platform offering. And you don't want to be too over eager with trying to create a completely standalone business. Even though you also want to be thinking of how could this be a standalone business, right? Like how could this revenue model operate independently? The second part of this question is great, which is how do you make sure your partners are being successful essentially? And it's got to be built into your observability from a product standpoint. So you should know the time from when you enable the partner to build to when they have their first success without needing to talk to them. Because if you have to continually be asking them for how they're doing, again, that operational cost is too high. So you should be able to have tracking and observability that says this partner reached out or connected or set up their account on this day. They had their first successful integration on this day. And looking at volume, looking at scale, it looks like they've rolled out to some percentage of customers at a certain day and then you can optimize for that. And that's one thing that we've been working on is how do we actually reduce the time to first integration and then to successful launch for the partner.

All right, we are going to do one more question and Then I think Saster will kick us off this Zoom. How established of a product in the marketplace should you have before moving towards becoming a platform? I have thoughts on this, Justin, but I will let you begin.

Yeah, I would say you should very much have product market fit here. So if you're trying to create a new platform, play a new product where you're trying to find product market fit with it, you don't want to be also trying to find product market fit with your core product offering. You want to feel comfortable in that. You want to feel some degree of comfort with the pricing and packaging for that product. And again, as we talked about before, you want to make sure that you can carve resources away from that product without killing velocity on the core product.

Yeah, I would just say it boils down to do you have a high quality existing product because you don't want to be fighting to making like creating APIs against a product that's not ready for it. So quality is huge. And I actually think Loom spent about nine months preparing for the record SDK. So quality and then I think it's ultimately signal. Right. Do you have partners and developers that want to build this with you? If you don't, then you're not ready and why rush yourself towards a distraction? And then I think the third piece, just building on top of what Justin said is do you have a team that is big enough that can handle a subset being carved out to go 0 to 1? I mean, everything with product is prioritization and this is just another huge prioritization question. So with that I will close this out because I think Saster is definitely going to need us to get off of this Zoom so we don't make anyone late for any other sessions at the conference. But I just want to thank you all so, so much. I know we have people joining from Uzbekistan and Mumbai, one of my favorite cities. And so I just wanted to say thank you all to so, so much. We really enjoyed preparing for the session and thank you for all the thoughtful questions. Please reach out to Justin and I. Awesome. And Justin, thank you so much. That was great. Tons of questions coming through. I love the chats blowing up. You guys are really engaging and interactive, so we appreciate that. And yeah, we've got tons of sessions going on digitally. We are checking in for registration live in San Mateo, so hope to see you all on a Zoom or in person.