Colin Nederkoorn, founder & CEO at Customer.io, on the CDP layer in messaging

How do you think about interoperability with other SaaS tools? What does it mean to "own" the CDP layer, especially if Data Pipelines works seamlessly with any SaaS? Is it more important that Customer.io "owns" the CDP, or that Segment doesn't and that the CDP is commoditized? I would love to hear, because Customer.io predated the modern CDP and Segment. Right?

We grew up around the same time. Technically, we may have been in the market first, but Segment was very soon after us.

When we launched in 2012, Customer.io was a paid product. We had a free trial, but we were always a paid product. One of the smartest things Segment did early on to really just widen their funnel as much as possible—I think it took them a couple of years before they had a paid plan. Early on when people were evaluating and adopting Customer.io, which was a very immature product at the time, we were doing okay, but people were still reticent to adopt us over much more established companies and products.

So, one of the things that I would say was, "Hey! Here's a recommendation that I would make—if you choose to test out Customer.io, integrate a CDP first. It's the same amount of work as integrating Customer.io. Then, if we suck and let you down, then you haven't wasted that integration work. You just point that data stream at someone else and you're good to go." It was really easy for us to point people at Segment to fulfill that need, and it was a great way to overcome objections.

As we matured, that became less of an objection because people were more confident in buying the product. Also, Segment introduced paid plans and then, they started to shift their focus away from our core customer. While it was still possible for our core customer to begin with Segment, we were seeing it becoming less common especially as customers started to scale. They really had this hard decision and often, people's Segment bill was more than their Customer.io bill. So, customers were faced with this hard decision of, "Do I use a CDP to integrate with my downstream tools? Can I afford to use a CDP, or do I just do these integrations directly?" 

For companies that weren't changing their stack that much, using a CDP didn't deliver a ton of value. So, people were not adopting CDPs. But that's actually not what we want. We want people to be using a CDP because that step of integration is so important.

As things shifted, one of the decisions we made was, "Hey! It's customers who integrate with a CDP and use Customer.io, that do a better job integrating the first time than the typical person who integrates directly." So, if we introduce a CDP, it's not our only product. We can help customers integrate the right way through our CDP, provide additional value by sending data downstream to other products, and then, also remove that hop from outside of our ecosystem into our ecosystem. If people are relying on us for really time-sensitive messages, they're not wondering “Why did it take three seconds?” or “Why didn't that message make it from the CDP to Customer.io?”

Now, it's all on us to make sure we deliver on that. 

Often, for companies, the messaging platform—Customer.io or something else—that's time sensitive. While it's great to have data in your analytics tool within less than a second, you don't actually mind if it's 10 seconds vs. one second whereas, with your messaging product, when someone's trying to reset a password, speed matters and it affects your customer experience.

That’s another reason why if we bring this in-house, we control the whole pipeline for the customer and can guarantee really fast speeds to get messages to their end user.

What are the benefits of vertical integration that customers get from bringing everything onto the Customer.io platform?

The two reasons that someone's going to benefit from using CDP and Journeys together is, there are fewer moving pieces in their stack. That means there's less to break, fewer things to diagnose, and you're not scrambling to figure out “Why is data not getting from A to B?” 

The other benefit is that we can bundle and enable lower cost of ownership. 

One of the things we're seeing from CDP as an industry is, it's an awesome product category, but there's not enough value in CDP, alone. A lot of CDP products are trying to bust out of the things people are buying them to do in order to generate more revenue per customer and find a way to be more valuable within a customer stack.

For us, CDP is a means to an end. We already have the thing that delivers a ton of customer value—our Journeys product. CDP is a means to an end for us. And so, it's less about maximizing the revenue that we're getting per customer and more about getting them set up with a great integration. So, by vertically integrating the two offerings, we can provide CDP in a really cost-competitive way because that's not the only thing our company does.

How does go-to-market (GTM) change with a platform approach? What's it look like now vs. what it will need to become an as-you-go multi-product? How do you see the customer journey in terms of adopting the Customer.io stack as it grows?

GTM's a challenge we're working on right now. One of the things that we wanted to make sure with our first new product—when you go from single product to platform—is that we weren't trying to sell to a completely new buyer. What we see is that, at most companies, it might not be the same person who's buying both Data Pipelines and Journeys, but the team buying Journeys and Data Pipelines are often deciding on the stack together. 

Perhaps you have—and this is not the real title—the data plumbing person or an engineer who’s on the data team at a company or on the growth team and they're making the decision on, “How do we get the data from our product into the downstream tool?”

Then, there’s the marketing team who's deciding, “How are we going to automate the messages we want to send to customers?” They're often making the decision on the stack together. They're typically buying the CDP or Data Pipelines equivalent before buying the messaging product. They want to make sure that the two are going to work together. We're not changing GTM too much but the one big thing we're doing is, we want to widen our funnel for Data Pipelines by introducing a free offering.

We're going to give people a million API requests per month to send data into Data Pipelines, and we're zero-rating that data to Customer.io Journeys. So, if someone wanted to use Data Pipelines with Customer.io Journeys, it's basically going to be no additional cost for the majority of customers. However, if they want to start sending the data to a bunch of downstream destinations, that's additional value that we're able to deliver to them. That's where they're going to start. They'll likely run into paying for additional API calls after that.

But the whole goal here, the real shift in GTM is that free plan. 

The thing we still need to figure out is how we talk about ourselves in our marketing since we're going to have two products now. Our homepage has always been very functionally oriented and targets the practitioner. In fact, our first headline there was, “Send emails based on what people do or don't do on your website.” Today, it is, “Build your dream messaging workflows.” It's very focused on sending messages.

We need to shift the way we're talking about Customer.io to the market to make people understand our full capabilities and the outcomes we drive for a business. That's a change that is definitely pretty new to me but we've been building out the marketing team in anticipation of this shift in how we talk to the market.

Right now, the Customer.io platform consists of Journeys (marketing automation) and Data Pipelines (CDP). How do you think about what products you want to add and in what order? How do more products drive more customer value and lock-in?

We're still really small as a company—230, 240 people—but we have really big ambitions in the long run. It's dangerous right now for us to get over our skis, adding too many adjacent products too quickly and just spreading our engineering team too thin. 

The way that I think about this is, our goal is to be core infrastructure for product-led growth (PLG) companies, much in the same way that Salesforce is the center of the world for companies who primarily sell via enterprise sales. So, when we think about the products that we might build, it's really about enhancing the experience for PLG companies.

There's these potential adjacencies, which we're exploring. But I want to be really careful about learning the lessons of other companies that have gone multi-product. 

One of the biggest challenges you can do or give yourself is to sell to a different buyer in the same organization. It's almost like you're starting from scratch and none of the goodwill is necessarily there. So, when we're thinking about, "Have we done enough for our core buyer, today?" I think there's still room for us to deliver more to the marketer and the data person in an organization. There's a lot more to do.

It'll probably mean adding close adjacencies to our existing product or reimagining pieces of the Journey's product into new standalone products. One of the things that we did in the past was, we added to our really robust segmentation by syncing it to ad platforms for ad targeting. That was not in our initial understanding of what people would be doing with Customer.io, but once you have a profile of every person who's using a product and all of this rich behavior data, it's a really natural extension to want to say, "Hey! I don't want my paying customers to see the ads trying to get people to buy the product if they just visit the homepage."

If we were to do that and be building that product or that feature again today, we might spin that off into another standalone product. But yeah, we're still considering what the next thing might be, realizing that, especially in larger teams, in larger companies, there are these different teams that have very specific use cases and they may not want everything in one giant interface. They may want a more targeted interface for their specific use case.

Do you see Journeys as the primary revenue driver with Data Pipelines as more of a loss leader? Are you imagining any new products as revenue drivers? How are you thinking about revenue mix and pricing for individual products and bundles?

When I think about revenue drivers and pricing, I try to align charging money for things with business success. For our customers, Journeys can be this massive driver of revenue. The way that I look at Data Pipelines is, it's primarily about efficiency and saving money and so, my general philosophy is, where we want our product to actually be a revenue driver for the business, it's a result of our customers becoming successful in their business by using the product. 

While it's really easy to charge for something if it helps someone else make money, it's much harder to make the sale if it's just about saving 20% on your integration costs or maintenance costs. 

In this world, we're trying to focus on building products, charging for them, and making our money when we make other people money and really just covering our costs when it's about efficiency.

In our last conversation, you mentioned Customer.io's customer base is mainly SMB and customers churn as they go enterprise. How has that moment of churn changed over time? How do you expect the platform approach to affect churn at the high end?

Our focus for a long time has been these mid-stage companies. If you think about it, early stage is a few people in a room; mid-stage, a folks have hit some traction—maybe there's series A, series B—and then, there's later stage or enterprise-y companies. 

One of the challenges that we had earlier was that we just didn't have the capabilities both in the product and our sales and services organizations to retain and service those companies. We haven't really tried to do anything differently, but we focused on building this really great, fairly priced product that's accessible to every business.

As the offering matures, especially in the current environment where companies of all sizes are looking hard at the ROI they're getting on their various products they're buying, Customer.io stacks up really, really well for larger, more sophisticated enterprises. We've seen over the past few years that we've been doubling the number of enterprise deals that we're selling every year—that's like $100K plus per year—and we're on pace this year again to double the number of enterprise deals we do.

There's still a few things that our enterprise-only competitors do that we don't—but functionality-wise, we're catching up fast—and those generally are not the core things that make the product work. They're like the enterprise-specific features that people really rely on. However, today, on the platform, we'll sign HIPAA BAAs and have SOC 2 compliance—a lot of the things that enterprises need to just even begin a conversation with us. While it's going really well, it's not an explicit focus of the business. We're building out some additional services on Enterprise CSMs now and have folk who are better versed at enterprise sales as well. It's going much better than when we talked two or three years ago. 

As to how the platform affects that, my hope here is that with enterprises, we've seen that sales cycles are long and the relationship with an enterprise can take a while to develop. We have a lot of the folks who are converting into paid customers and we've talked to them multiple times over one to two years. What I'm interested to see and hopeful for, is that CDP becomes a way for enterprises who have contracts on the marketing automation side to start using us for CDP, and that gives us a foot in the door to then sell Journeys.

We integrate with all of our enterprise competitors on the CDP side, and I think that there's a lot of opportunity for us to earn business from that initial experience of enterprises because those are also the folks who we see are often pretty frustrated with the typical CDP providers.

CDP has got a little confusing as a term. It might include ETL, reverse ETL, data enrichment etc. How are you defining CDP at Customer.io? Where do you see the opportunities to build a feature-rich experience at the CDP layer?

We're still in early access, and I expect that our feature set at launch will let people pull data from a database, warehouse, send it to us via our API, or through integrations. Then, they'll be able to filter and transform that data like some PII you don't want to send to some system. 

Within Customer.io Data Pipelines, you can choose what of the data you send us gets passed on and in what shape to your downstream systems. They'll be able to send it downstream to all the various tools that the business uses. That's fundamentally what we and many of our customers understand CDP as. But we see different portrayals of this in the market.

Regarding the goal with CDP, right now, it's still a very engineering-heavy task. So, one of the opportunities is to decrease the engineering burden and increase marketer independence. What we're really looking at is “How do you make CDP a lot more accessible to marketers or less technical folks who are responsible for getting all of the data or using the data in the downstream systems?” “How do you make it more self-service rather than relying on your engineers to own what happens post-integration?”

We're exploring it right now and it’s still early days so we don't have answers quite yet. One of the things that we were successful with was making this really technical—our Journeys tool—which is really advanced and goes really deep making it accessible to a lot of people. We hope to do the same thing with CDP. We've got folks on the team who can do it but we just haven't got our V1 one out yet.

Customer.io Journeys needs a low latency CDP to make sure messages are sent to users in real-time based on actions they take in the app. Is speed a differentiator among CDPs? If so, does Customer.io intend to compete on that dimension?

My impression is that speed is not how people make their buying decisions, but it definitely affects the post-purchase experience. If things are not getting to where they need to go fast, then sometimes, customers write to us that their CDP is not getting or they're not seeing stuff get from the CDP to Journeys fast enough. But it's generally not a buying decision. 

If we decided to market ourselves as the fastest CDP, I don't think that would necessarily win buyers. But it is a really important characteristic once you get into production. The challenge, however, is for a lot of folk that's too late in the process. I don't think we will go there. 

If we talk about the way that speed shows up, it's really about the latency between getting data to your CDP and then, sending out the message or sending out a message in your automation product. That's something we can do, but that's really the Journeys buyer pushing the decision to buy CDP as well rather than the CDP buyer.

Is data warehouse sync part of CDP or a separate product? How do you see the relationship between CDP and "modern data stack" in terms of data infrastructure to power things like Journeys? Is the data warehouse sync a differentiator for Customer.io versus competitors like Braze and Iterable?

What we're seeing from customers and our early access folks is that data warehouse sync is absolutely part of CDP. Many people won't use CDP if there isn't the ability to pull some of their data from a data warehouse. We were planning to have that in our GA (general access) when we released the product to the market but that wasn't initially part of CDP. 

It was really about real-time integration and then, federating out that data but that became important as the data warehouse increased in prominence. However, it was only in the past five years that pulling from a data warehouse into your stream of data became a thing. Now, it's important.

I would say absolutely, data warehouse is part of the modern data stack, but there are cases where you can't rely on the data and data warehouse alone. The modern data stack has data warehouse plus real-time and it's important for companies to deliver a good experience to their customers that they're doing both, not just one.

As far as differentiator versus competitors goes, we're not looking at Braze and Iterable in terms of how they stack up as a CDP, but my impression is that they do pull from a data warehouse, though they don't have a lot of the capabilities of federating data on downstream that we've got in Customer.io Data Pipelines.

How do you position Customer.io's CDP against standalone products like Segment, mParticle and Rudderstack and the CDPs of other products like Klaviyo, Intercom and Amplitude. Do you intend to win based on vertical integration with Customer.io Journeys? How about price, feature differentiation, and number of integrations?

Winning with CDP for us is really giving our Journeys customers—current and future—a really great option for CDP functionality that gets data into Journeys and everywhere else it’s needed. That's really the gap that we were trying to fill in the market. When we looked around at the options and saw the choices that our customers were making and why they weren't adopting CDPs, we wanted to try to address that and make it an easier decision for them. 

A lot of the folks that we hope adopt Data Pipelines—and we're seeing strong interest from—don't use a CDP, today. They're not necessarily switching from an existing CDP, though we're happy to service folks who are doing that too. We just want all of our customers to be using a CDP when they use Customer.io. We’ve done our part to encourage that usage, but it's a lot easier for companies to buy from one company to use Customer.io than to buy two pieces of software from two different companies just to get Customer.io Journeys set up. Compared to the standalone products, our goal is to be really competitive on price, have the features that the majority of folks need, and all the key integrations that our customers care about.

As far as other products that also have a CDP are concerned—Klaviyo, Intercom, Amplitude—I haven't played with Amplitude CDP, but I think that's the only one of the three that actually is a CDP in the same way that Segment, mParticle, and RudderStack are CDPs. I think other folks are borrowing that term, but they don't actually offer that functionality.

Klaviyo launched its CDP as part of its enterprise platform. Are you primarily thinking about Data Pipelines as driving enterprise lock-in and all-in-one? Do you have a downmarket strategy for Data Pipelines? How do you think about what Klaviyo and Intercom are doing?

If you just use the words customer data platform, they have a platform that contains customer data. They might have connections to other applications that send the data to those other applications. But like I said earlier, our customers expect to have reverse ETL. They expect to be able to pull from a data warehouse, manipulate that data, and put it into our system and other systems. That's not a part—as I understand it but I may be wrong here—of what Klaviyo and Intercom might think of as CDP. 

I don't even know if that's part of what Amplitude thinks of as CDP, but certainly, for Segment, mParticle, and RudderStack, that's functionality, which is table stakes in the category. So, I'm not entirely sure what people think they're buying if they're buying CDP from the other folks.

I suspect that a bunch of their enterprise customers were, or their larger businesses were saying, "Hey! We've heard we should be buying a CDP and Klaviyo together." Klaviyo possibly said, "Look, we have all these connections into other products." Klaviyo is a CDP, so, that helps them in their enterprise sales motion. 

Again, I don't think the functionality is quite what other folks are buying when they're buying a CDP. I think it's a largely closed system that's not about federating your data out to other platforms. You couldn't buy Klaviyo CDP and then use some other service like Ontraport for instance.

I don't know all the ecommerce-focused companies, but you couldn't buy Klaviyo CDP and use some other ecommerce email provider to send your ecommerce emails. However, you could use the Customer.io CDP, Customer.io Data Pipelines and use Braze or Iterable to send messages to your customers. It's just fundamentally a different thing. 

Our goal is never to create the conditions for lock-in. That's part of why we're committed to sending data to people who we might view as competitors to the Journeys product. We want to win on our merits as a company. We believe that it creates goodwill to customers if you serve them really well so they'll choose to buy us and stay with us, not because we made it so hard for them to leave, but we made it so great for them to stay. 

A big part of our strategy is to build the CDP that works with every destination and doesn't try to keep customers only in our ecosystem or make it super hard for them to leave. To the extent that we can make the experience of working with Customer.io as a company, as a product, and our various products really amazing, we think customers will choose to do business with us for that reason rather than, because once they're in, it's so hard to go.

There’s a common pitfall of going multi-product by selling into multiple buyers. As you launch more products, what do you see as the boundary conditions that define what Customer.io should and wants to be doing vs. what it won't do?

We're a horizontal platform and we want to compete where we know we can make an impact in a market and create a solution that works for the majority of our customers. Since we serve both B2B and B2C companies, some of the solutions to problems can look totally different depending on the type of business.

From an ego point of view, it would be awesome to have a help desk tool and a sales CRM. But a B2C CRM looks totally different from a B2B CRM. So, for us to deliver on our promise to customers, we might be able to do that by building great integrations into the top B2C and B2B CRMs. If our goal is to have data from CRMs in the customer record and Customer.io and then surface the data that we have inside of the CRM, then we don't need to build the software to do so.

We just need to commit to either, a) make it easy for other vendors to get that data from us, or b) do the heavy lifting to make sure that our customers can build the views that they need to use the data that they're storing with Customer.io in all of the different places that they're using it. At the same time, we know that getting data from all of the different places that businesses are interacting with their customers, getting that, and leveraging that in Journeys will make the opportunities to send better messages, even greater. That data, in most cases, is not there yet.

We definitely have some work to do, but it doesn't necessitate us to build a sales CRM. While I wouldn’t rule out the boundary conditions, these are probably things that go outside of customer communication and interacting between a business and a customer.

We used to have a boundary where we thought we'd never be inside of the product really, but one of the expectations for mobile apps is an in-app message, in-app notification. We built that experience and so we exist inside of our customer products now. But really it's about the communication piece once someone leaves a product or outside of the core experience that our customers build in their product.

Intercom used to have a platform approach, with marketing automation and support built on top of a CRM. It's now decided to focus 100% on customer service. Why is now the right time to try this platform approach and how will Customer.io succeed where Intercom decided to pull back?

I think we could build a $100 million a year business just doing marketing automation alone. There's lots of examples of that, but I draw a lot of inspiration from Salesforce, Atlassian, and even Microsoft. 

One of the things Microsoft focuses on, measures, and shares publicly is how much their partners make for every dollar that Microsoft makes—for every $1 Microsoft makes, their partners make $10. We're just getting to the size where the ecosystem around Customer.io becomes really interesting to partners and I'm really excited to try.

I hope we're successful. It will take a lot of work, but to try to build an open platform where other businesses can service the customers who have adopted our platform and build on top of us, will allow us to not necessarily build the in-app notification product that meets every business's needs. If you try to build essentially one version of every tool in a platform that only meets the needs of a single business, it's really hard to know who your ideal customer is because there's a ton of nuance.

Our customers who have the same needs across marketing automation, for instance, if you're a million customer edtech company, in marketing automation, that might look pretty similar to a million customer health company, but in practice, in every other part of the business, you're completely different. So, it's near impossible to get it right once you get into these different products that you're trying to cross-sell into your customer base.

What I'm really intrigued by is if we can get that core customer profile data for product-led companies; if we can be that source for them and build a really robust ecosystem around that, then, maybe we can have other businesses that build their products on top of the data that's in Customer.io and potentially augment the data that's there. That's the really big opportunity that I'm excited about.

That feels pretty different from how Intercom approaches building a platform. Not that I think their approach is right or wrong. It probably made a ton of sense for them at the time, but I think we would approach it trying to be a lot more open. This is a decades-long challenge so you're probably not going to see the results of this next year.

Where do you imagine that Customer.io can get the most leverage out of AI? How are you thinking about AI at Customer.io re automating writing messages, creating segments, enriching data etc.?

Today, your customers and your team are already using AI whether or not it's in a product or your product. In our company, we've got people fixing HTML errors with AI. They're translating messages where there's markup inside of those messages and that's historically really hard for Google Translate to translate your message. But AI seems to be able to manage with liquid tags or with HTML tags in it. Totally fine. I think LLMs provide a ton of value on the surface of a tool like ours. 

So, with things like a text prompt to build a workflow, there's a very clear line of sight to adding a lot of functionality like that or your standard things like image generation, write me an email that encourages people to come back to my product. All of that stuff is really easy to imagine how you integrate that into a product like Customer.io. 

One of the approaches that we've taken is, we're working on this stuff in the background, but it's not a key priority in the business right now. The reason for that is it's developing so fast that we’re making sure we're up to speed on it. We've done some hacks in the product leveraging OpenAI and GPT-3, GPT-4, but we haven't released anything to customers yet. I would expect us to this year.

We're taking a fast follower approach because while AI is going to affect every business, our business is not an AI business. So, we're looking at the most interesting applications of AI that are adjacent to ours, and we want to learn from the experiments that other people are doing before we commit to how it's going to be transformational to our product. 

If you do it right, it's not just a text input box next to your email composer. It's deeply interwoven into how your product works. That's what we want to do. But it's unclear right now what the best opportunities are to do that.

To the extent that Customer.io helps enable a specific PLG sales motion for its customers, how concerned are you that the way that customers buy software in general will change with AI? What risk is there that, e.g., marketing automation becomes a lot less effective as a result of a dramatic rise in spam and that tools like Customer.io lose their alpha?

I tend to be an optimist and the optimistic view on AI is that it dramatically increases the quality of everything that happens. So, if it can improve the automations that people are creating, they're better targeted. The messages are better and so is the visual design. 

The glass-half-full view is that actually AI is an accelerant on helping us on our mission to help companies send messages that people want to receive. There's a case that the spammers and the bad actors just bombard you and old techniques for spam filtering fail us. People are just overwhelmed by messages from all angles and start to tune out. That will happen. But we'll find solutions to those problems. If you're a business that's doing a good job with engaging your audience, connecting with your customers, then, you'll be able to take advantage of it to do that even better. 

That's what we're hoping to enable. What's great with AI is that tools like Customer.io don't end up losing their alpha. They become more accessible to more people who are then able to use them and be more capable in a tool like Customer.io. The net result is that what their customers end up receiving is better than what they were getting in the past. Potentially, it’s really positive for our platform.

If everything goes right for Customer.io in five years, what does it become? How do you see the world change as a result?

In five years’ time, if we're successful, potentially we're firmly in people's minds as the platform for PLG companies to use to manage all of their customer interactions. 

We should be able to get some of the way there in that time. We talked about this with Sacra before—if you're a sales-led growth company, Salesforce is your tool. If you're a marketing-led growth company, then, HubSpot's your tool. If you're product-led, then, Customer.io is your tool.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.