Devang Sachdev (Snorkel AI): Platform GTM

Devang Sachdev: The whole point is that they are bringing the problems that you've not seen before. And diving a little bit deeply into, what would you do to inspire and educate? The first thing that you need to do is deeply understand the builders and their motivations.

Blake Bartlett: Welcome back to The Build Podcast. I'm Blake Bartlett, a partner at OpenView. The world of SaaS is always evolving and we are here to help you adapt, compete and win with your startup. The Build Podcast brings you stories and insights from my conversations with the most successful people in SaaS. In today's episode, I chat with Devang Sachdev about platform, go- to- market. Devang is a marketing leader with strong product marketing roots at Twilio. And today, he's the VP of Marketing at Snorkel AI. He points out that these days, everyone is quick to declare themselves a platform but he clarifies the actual definition to be a product that other people build on top of. So, you're offering customers a starting point to build their own solution and not a finished product that they use off the shelf. And if you are indeed a platform under this definition, well then you know that go- to- market for platforms is fundamentally different than others software products. Devang walks us through his framework for how to win the platform go- to- market game. All that and more on this episode of Build. So, let's dive in with Devang Sachdev. Today we're talking about bringing a platform to market and what it means to practice platform go- to- market. And before we get into some of the meaty, how- to stuff, I think it's really important to start with definitions. Especially these days, everybody wants to say that they're a platform or declare that they're a platform and that word gets thrown around a lot. So, let's start there with definitions. In your world, from your view, when we talk about a platform, what does that mean?

Devang Sachdev: Yeah. You bet. Just to take folks down a little bit of a memory route here, I have been working with platforms and marketing platforms for almost a decade now. It started with my work at Nvidia where I was leading product management and engineering for GPU computing, which is a platform over which many different businesses and solutions have been built, including HBC and now Nvidia's AI business as well. From there on, I've spent almost half a decade at Twilio, which is a platform for cloud communications with lots and lots of use cases that span the communication spectrum. And then most recently since last year, I've joined Snorkel AI, which is a platform for AI application development. So, in my mind and through my experience, when I think about any kind of software, software's always built in layers. The very bottom of the layer is infrastructure. On top of that, you have platforms. On top of that, you have applications. And on top of that, you have services. Now, what most product builders believe is that the lower you are in the stack, the more valuable you are. Which is why a lot of services companies say that they have products or applications. A lot of app companies or application companies say they are platforms and so and so forth. In some ways it's similar to what Peter Thiel thinks about monopolies in business, where non- monopolies try to be monopolies and they're talking to investors. A lot of applications pretend that they're a platform because in their mind it has been, users won't see a path to competition by providing a better application experience. So, to a degree, practically almost all SaaS vendors or SaaS builders talk about their product as a platform. But the reality is that not every SaaS product has to be a platform. In many cases, it is a rich application with lots of integration points, which in some cases have become table stakes for modern tech stacks. What is most important and it's not as if platforms are better or applications are better. What is most important is to know who your user is and what market are you targeting? And the real purpose of the platform is to be able to enable users to be able to build applications on top of your platform. That's what is the defining factor of a platform. In fact, a user of a platform, I would call a builder and funny enough, the title of the podcast series is Build. So, it's quite appropriate. But when I think about, again, coming down to this definition of a platform in the very early days of software, platform would have a complete software programming environment. The under line subsystem with language or runtime components or even libraries or binaries. I would think about things like microsoft. net or Java and applications would be built on top of such a platform. 10 years later, it was less about the underlying computing system and it was more about the broader ecosystem. This is when iPhone or AWS or force. com is what became a definition of a platform for us. But in reality, what these types of products or platforms did, was it disassociated the compute but it also provided ways to integrate other software streams. It provided the capability to extend the current design from what the platform has provided as a product into almost an endless scope. Meaning that builders were able to do things that initially the product was not built for and that's what makes it a platform. And then recently, when you think about microservices combined with cloud platforms like AWS, Azure, Google Cloud or even Twilio or Stripe, what these platforms have done is they have been able to bifurcate the logic from the applications. And this is what gives maximum flexibility for these products to be platforms. So, in my mind, a true definition of a platform or in a short way to define a platform would be to allow users to build applications often that have not been initially thought about when building that platform and giving users that maximum flexibility.

Blake Bartlett: One of the things you said there was how you think about who uses it. In an application sense, it is a proper end user of the product but then on the platform side, it's the builder. And that difference between an end user versus a builder, which then kind of correlates to what does one do versus the other? An application does something out of the box. It solves a specific problem for that specific user and you can kind of turn it on and go effectively. And then on the platform side, because it's oriented toward the builder, it kind of does less out of the box. It has a bunch of things that you can put together and sort of stitch together and building blocks and tools but you ultimately have to bring the problem to the platform and determine what you're going to build. And that's kind of the fundamental difference.

Devang Sachdev: I love like how you stated that you bring the problem and then platform becomes the solution or with the platform, you build a solution versus you seek a solution that you directly apply. And again, that is another way of looking at what a platform definition or an application definition would be.

Blake Bartlett: For a customer, if you're in the position of looking to solve a problem in your business, what would take you down the path of looking for an application versus looking for a platform? Is it something around perhaps how bespoke or how unique that problem is to your own business versus how common it is? Or is there a different rubric that somebody should use to determine," What should I get?"

Devang Sachdev: In the spectrum of customers, it can range quite a lot. Certainly, lessons from the tech world are that when you build, you are able to create an increasingly larger gap against your competition, whether you're building a solution for customer service, for your organization or whether you're building a solution for accounting for your organization. But when we look at lessons from the Silicon Valley, we often say," Building is better than buying." I think there's a new sort of consciousness that's rising within the tech world, which is around," Build what you can. Buy what you can't." And that is also influencing a lot of this decision around," What do I want to go purchase? Do I want to go purchase an end application that I can simply use?" It is out the box, like you said. It is foolproof. It is meant for a user who is looking for operational value rather than customization. And the sophistication of that user in terms of using the technology or in using the guts of that technology especially, is low. So, that's one... Or is it more so that," No, I'm looking for a platform whether it is the lowest level of abstraction in the technology stack or a bit more higher level of abstraction, depending on the flexibility that I need against again, the sophistication of my team." So, if I were to go at the very lowest level of abstraction and think about," Let me just use AWS or Azure and build the entire application stack myself." Do I have the time, resources and expertise to be able to build all of that or do I want something that's a little bit more baked in a building block fashion that gives me acceleration towards building the application but not necessarily requiring me to reinvent the wheel for things that may not be part of my expertise or just not necessary to build given time constraints.

Blake Bartlett: So, we've already started to talk about it but the differences between an application and a platform. But let's unpack that a little bit more and perhaps a way to think about it is, what does it take for an application to become a platform?

Devang Sachdev: Through one of my experiences, I have gone down the path of brute forcing an application roadmap towards a platform roadmap. And through that experience, I would say that it's not a very productive venture for a couple of different reasons. One, when you have built an application, you've probably created hundreds, if not more features and you've done it against a very pre- defined set of use cases or solutions as we would call it. And against that, you've built very specific predefined business logic off your application. And this is what's going to limit the scope and the flexibility of your product and it's intentional because that's what the user needs. Its coming back to this idea that the user is what should drive the decisions that you're making regarding an application or a platform. If at any point, as many founders and many product builders will experience that they will look to see that," Do we have the ability to capitalize more market," or," Transition from an application to a platform?" There are few things that I would say to inspect and really determine if that's the right course or there's a different course to be taken, which is a completely native or new organic design or organic development. One of the reasons why application builders struggle to transition into platform builders is because building a platform is time consuming and resource intensive. There's a lot of stuff that you are going to expose that is sitting underneath the hood of the application. And it is frankly, less exciting than creating more new features and talking about those new features. But it's important when you're building a platform, you have to invest into those core underlying capabilities because if they're not first class citizens, then the stability and the usability of that platform might not be as first class as your users would expect. The second thing is building platforms is also more complex because you are building against a somewhat of an endless scope. You want to create a large amount of flexibility. So, monolithic applications need to be broken down into components. There are features that are interdependent and a lot of organizations go through a re- architecting process and creating layers that are for new services or new levels of security. So, if your application is not easily decomposable, it might be better to start with a net new set of product code, rather than trying to refactor it. Refactoring it might end up costing you more time and money and resources. So, that's another reason. The last one that I think a lot of organizations don't notice or a lot of founders don't notice when they get started on this journey is that there's a big difference on how you monetize an application versus how you would monetize a platform. In often cases, platform monetization could be done by usage. There is a big factor in terms of platform ecosystem. So, there's an opportunity for pass through revenue to be developed to a partner ecosystem. There is an opportunity to monetize with the number of applications that a user is building on top of your platform. So, there are multiple dimensions in which a platform can be monetized. And in making that transition from an application mindset and development mindset to a platform mindset, keeping your pricing and keeping your monetization at the forefront can help you make that transition rather in a straight forward fashion.

Blake Bartlett: So, a lot of really good detail there. I think one consistent through line that I took from that is that it's not easy to build a platform, especially if you're starting from an application. So, proceed with caution as opposed to what I think a lot of people assume is just that it's an inevitability." Every application will become a platform. It's the journey everybody takes. So, we're going to do it too." And also, there's an assumption in that it will kind of be like it was when we launched the application in the first place." It will be more straightforward. It will be a little bit more of the same." And what you're saying is that," No, it's fundamentally different." Everything about building and taking a platform to market is fundamentally different. So, again, proceed with caution and it's not necessarily an inevitability.

Devang Sachdev: Absolutely correct. And would love to dig into it. Now that we have a platform at hand, how do we take it to market?

Blake Bartlett: Yeah, that's perfect. Let's get into the specifics. So, what are some of the actionable steps and core strategies that you recommend when you are marketing or taking to market a platform versus an application?

Devang Sachdev: Similar to how you build a platform, there are nuances and differences when you're trying to market a platform. For me, through my experience, I've discovered that platform marketing is equal parts inspiring your audience and educating them. And when I talk about inspiration, what I really mean is inspiring builders by celebrating the success of other builders and what they've built using your platform. That works really well, which is why you see programs from companies like Salesforce that are called Trailblazers. They're celebrating the success of people who have built good applications for their company using force. com as well. And then education is to educate new builders or prospective builders on how do they build amazing applications on your platform too. And these two need to go hand in hand. If you just convey the goodness of your platform from a speeds and feeds or feature standpoint, and oftentimes the question will come," What can I do with your platform?" And oftentimes the response will be," Well, you can do whatever you want with this platform in this domain," whether it's a domain of communication or CRM or data management or whichever other domain you have picked up to build your platform in. But the biggest problem that new builders have is they need a starting point. That might not be the point where they dig in and end but that would be the point where it will help them to at least understand your platform and its value a little bit more clearly. And then be able to think through," How do I apply this technology, this platform to my use and to my problem," as you said, because the whole point is that they are bringing the problems that you've not seen before. And diving a little bit deeply into, what would you do to inspire and educate? The first thing that you need to do is deeply understand the builders and their motivations. Why are they seeking this building block technology or platform rather than building it themselves? Why aren't they seeking an application that could lead them to a solution much faster rather than having to put in the work? And navigating these twins of the spectrum is important because it can help you define how you create value around your platform. So, one way of really understanding your builders deeply is to have builders on the marketing team, especially for enterprise technologies. Marketing teams sometimes sit on an island or a silo because they're not the day- to- day users of a platform, they understand the product through other people within the company, which is essential. But by having some part of the team truly in the persona of a builder that the marketing team is marketing to, would be essential to have that DNA across every function within the organization that who we are building for. When we discuss, how do you orient your team around it? I can speak specifically about, what does it mean to have builders on the marketing team? So, that's the part about being able to discover channels that you need to connect with the builders. That's the mechanism in which you are able to understand the builders a little bit more deeply. And then the second part of having platform oriented marketing is to constantly stay connected with your customers and discover ways in which that they are using the platform because that's where you are going to learn what new solutions is your platform delivering? What type of problems has your platform solved that you didn't see before? But you need to add to your portfolio of solutions or portfolio of problems that your platform can solve and present them back to the market, hence increasing that starting point for all types of builders or all types of users who are attracted to your platform.

Blake Bartlett: So, you mentioned something there about solutions. I think that's another word that also probably needs some definition because a solution is a very generic term for a lot of different things. But I think in the context of platform, as you're talking about, it has a very specific definition. So, can you talk a little bit more about solutions and then talk about solutions and a focus on solutions in the role of doing that in platform go- to- market?

Devang Sachdev: A lot of organizations will invest in some sort of solution marketing effort. Question is, during their organizational journey, when would they invest? And my experience has been that if you are building a platform, the sooner you invest into solution marketing effort or function, the faster you will see adoption of the platform. And so, one way that I think about solutions are, what are all the possible use cases at a few different levels of abstraction? One level of abstraction could be, what use case am I solving for a technical user of my platform? The person who's actually building and using the platform day in and day out. And you can call these things technical use cases. Another type of solution library or taxonomy could be built around business problems. And these are things that, what business problems are the solutions that are built on my platform used for? And then the third type of solution set could be around industry specific problems. And the reason why you have... Well, I think about these three layers of abstraction is because at any point you are engaging with these three different types of personas when you are introducing your platform and the value that each of these users get or each of these personas get is slightly different. So, why the technical user might be more concerned about whether there is a certain feature available within the platform, then solution marketing alongside the platform marketing team can deliver that message. When a business user, oftentimes a product manager or oftentimes an analyst would be seeking to evaluate a platform. They'll be seeking," Has this problem been solved by this platform before? Does this platform even offer any promise that it will be applicable to helping me solve this particular business problem?" You want to convey that point to such a persona. And then from an industry specific problem, oftentimes both technical as well as business users will seek validation whether a certain platform is applicable within that industry. And does it have the breadth, the horizontal scope to be able to be very applicable within their specific domain? And this often ends up becoming a conversation or a decision point between whether I'm buying a platform or I'm buying an application. Especially when you think about the application specific go- to- market, having an industry focus can accelerate your adoption within that particular industry for that application but oftentimes platforms are built horizontally. So, you need to have at least some value messaging that is specific for industries that you have prioritized. And it comes over time. Certainly, you cannot create solutions and marketing around all of the three axis that we described, the technical axis, the business axis and the industry specific axis at the same time. But the more you think about this as a progressively larger scope for your solution marketing team and the sooner you think about it, the faster your chances at getting adopted. Now, paired with the solution marketing team are two or three other teams that need to participate. One of them is what I call, core platform marketing. In a application specific world, this could be a product marketing team but this is the team that describes or this is the function... Doesn't have to be a whole team. This could be someone owning this function or owning part of this function. It defines and describes the shape of your platform, the core value of your platform, what features exist, why are they unique or which ones of those features are unique, which one of those features are comparable, which features are holistic and what's on the roadmap and is more closer to the product itself rather than the problems that exist in the market. So, there's a yin and yang between these two functions and it's very critical to have both of them develop early within a platform marketing organization. I'd love to touch on one another function but I wanted to see, Blake, if you have a followup question regarding solutions.

Blake Bartlett: I like the different levels of abstraction that you had talked about earlier in your description there. The example that comes to mind for me is something like an API where you need to both speak to the developer that's going to be using the API and they're going to care about," What does the API do and how good is the API?" But then it doesn't stop there. It obviously has to then drive business value and be able to be built upon in order to solve a real business problem. And so, you need to then speak to... Getting it to the solution level, speak to the business value that it will deliver. So, you have to check both boxes and that then influences who you need to have on your team. You can't have a general purpose marketer who's going to be able to do all of that stuff. Like you said, having builders on the marketing team. People who have that empathy and understand what it's like to solve these problems themselves, speaking to those different levels of abstraction or those different levels of what you're building. So, awesome stuff on team there. What else in terms of rounding out the go- to- market team?

Devang Sachdev: Coming back to the point you just mentioned, which is having builders on your team. I have often relied on my friends in the developer network world or developer relationships teams to be able to truly understand the builder persona that we are marketing to. And on a marketing team, having a developer relationships function really helps you build that bridge in terms of connecting with the builders and helping them educate, speaking in the language that they speak. Oftentimes building marketing specific, whether it's content or artifacts or enablement for sales, in tools of the choice that builders have chosen in your domain. And through that also discovering what channels and mediums are the best way to approach developers or builders in your domain, whether it's a community that consumes more video content, whether it's a community that enjoys more in- depth tutorial based blog posts or whether it's a more live conversation and in- person engagement that this community seeks and consumes information. So, investing in a developer relationship function in addition to having somewhat of a traditional product marketing function that we discussed earlier as a platform marketing and then having a solution marketing function. Having this tripod of functions within marketing organization and being surrounded by your traditional marketing organization, which is growth or demand generation based efforts, communication based efforts or corporate marketing based efforts would be a good way to approach a more platform specific go- to- market.

Blake Bartlett: Perfect. Devang, we have covered a lot of bases here from the definitions of a platform, which is an important starting point to the key differences between an application and a platform. And then obviously, how you need to think about the downstream implications of go- to- market based off of some of those root differences. And then ultimately, how to construct your team to actually pull this off. So, masterclass on platform go- to- market, complete. Thank you so much for walking us through all of your wisdom and all your thoughts here.

Devang Sachdev: You bet. It was a pleasure to share this.

Blake Bartlett: Thanks for listening to this episode of Build. If you like what you've heard, leave us a review on Apple Podcasts and subscribe to stay up to date with all the new episodes. Want more insights from OpenView? Follow me, Blake Bartlett, on LinkedIn for daily PLG content and head to our website to sign up for our weekly newsletter.