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

Hi, my name is Nique Drumwright. 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. Um, 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 to 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 @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 vegetablesready.

All right. With that incredible factoid, let's get started. Um, so we have released the Loom SDK platform in the last 6 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, really admire. We will begin by giving a little bit of background information on, 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, 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&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, Aneek. 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.

Good. And a little bit more background to make sure that, that we're all accessing the, 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 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, 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, it 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. So this is really Loom. And so kind of 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, the product market fit of the product really accelerated and Loom recoursed its its desktop recorders, and also in 2018 released its embed SDK. And, uh, 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 transitioned from working in the office to working remote, we began to see a significant amount of inbound, both from developers and also from partners, to 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 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 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, 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, 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, that Justin can definitely attest to is when you're, you're going zero to one, 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. We 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 gonna be talking a little bit more about the partner side in a couple slides. The final point I want to make here is, is capacity. So for us, with our platform, we wanted to be investing in it much earlier than we, we ended up actually making the investment. And, you know, 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. Um, when you can imagine the number of people going to try out Loom all at once definitely made, uh, more than one database crisis. So 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, you're gonna 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, the 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 Anik 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. Um, 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 2 to 3 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. In 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 a— in going to zero to one, 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 out to market. I think the other 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 in 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 one of 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 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 and 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 zero to one, and we should have done the exact same thing on the product marketing go-to-market 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 to. All right, Justin, I will turn it over to you.

Great, thanks, Annick. 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 3 examples that we're going to be sharing here, that's 2 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, 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 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, when you're getting started and you're experimenting with Twilio, that it's, it's, 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 Stitch is a, is a brand new player. So it demonstrates that you don't have to be a very established, you know, company being around for a decade to do some of these things. Stitch actually started in 2020. Uh, the co-founders were ex-Plaid, which is another fantastic example of a platform. But Stitch is an authentication platform. And what they do really uniquely is that in their documentation, they start with templates and 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? What— 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. A— 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&A, if we could go back in time to sum up our hard lesson learns, I think like one thing to definitely anticipate is that partnerships discussions are lengthy. And I think one of the, 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&D resources, because this is a totally new motion. For your company as you expand from B2C to B2C+ 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, et cetera, 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&A that we, that we got in. So Justin, I will I'm going to 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, 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, um, in the other direction. It's, 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's— 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-sized to the investment to know that you have the capacity as well? So what's the potential return on this? How much is 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 to 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, right? So when you're, 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 eng team. 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 am 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? And 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 Loop, 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 generations where it's, you know, a paid SDK. We are still exploring that option. 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 we share a little bit about launch success.

Uh, the only thing I'd add in that is it's just, 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, your go-to-market involves both your core product market offering and the platform offering, and you don't want to be too overeager 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? I would— the second part of this question is great, which is how do you make sure your partners are, are being successful essentially? And it's gotta 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 room. 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 9 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 zero to one? 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 Sastre 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 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 thank you so much. That was great. Tons of questions coming through. I love the chat 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.