Pulkit Agrawal, co-founder of Chameleon, on software that drives product adoption

There was a really good example from one of our customers, Chili Piper, who knew based on their app data, when a user had hit a limit, and then prompted them to have an upsell conversation, sales assisted, speak to a rep, but prompted them in the application at the right moment. And that, I think, helped them close something like $150,000 ARR within two or three weeks of launching that campaign. So that's a really, really nice coming together of PLG—but it's not pure product—it's PLG with sales, with customer success and support. It's data driven, knowing what you know about the user.

PLG has led to increased demand. The modern data set consists of the storage, of course, your warehouse, your lake, or whatever, your collection, how are you collecting, and maybe you're using a CDP or something, related piping like ETL or reverse ETL, some analysis, whether it's a BI tool or event-based analysis tool. But then the other piece of it is, ‘well, what are you doing with all of that data to then act on it?’ Now, some of it is like, ‘okay, we're doing analysis and that's informing our product roadmap,’ fair enough. But I think there's a lot of power that hasn't been unlocked, which is around real-time engagement of users based on that data.

Using reverse ETL or something to get data out of your warehouse and into the likes of Chameleon, to trigger an in-app experience that's exactly at the right moment based on what a user is at the product. I think that's coming. We also recently, for example, added some optionality to trigger experiences based on custom logic, based on the state of the user in the app. There is some stuff like that happening, but still much of the value of the modern data stack in how you communicate to users in real time, is still to come.

Can you talk about integrations? What does a typical user's related tooling look like? What does their stack look like with respect to some of this stuff? Is the quantity and depth of your integrations an actual competitive differentiation, or is it just table stakes to being part of the modern data stack?

There's probably two categories of integrations. One is data integrations, and those are somewhat table stakes now. There are differences.

Our support around our Segment integration is superior to some of our competitors—we support nested properties, group properties, and there's all of these little caveats to how the data syncs, but it's hard to really communicate all of that to the market easily. Let's just assume that those are table stakes. You’ve got a Segment integration, fine, and you've got a Mixpanel integration, and maybe you have a two-way sync where you can pull cohorts from Mixpanel and use that for targeting your experiences, and send your events to Mixpanel and the like.

The thing that we're doing and pushing—which I think is differentiating, and we're trying to capture that more in our messaging—is these extensions that we've also built.

How do you bring functionality from other tools into the product through Chameleon? A really simple example is launching a Typeform in-app using Chameleon. So you want to collect a bunch of fields, but you don't want to take people to a different page because you know that leads to drop off. Opening it as a model in-app without having to install Typeform code anywhere—that's an embedded experience that Chameleon can offer, and we did the same with scheduling solutions. With Chili Piper or Calendly or HubSpot, you can prompt someone to book a call in-app.

We recently launched a Figma integration, so you can show someone an embedded prototype, which can be great to demo something or collect feedback.

We're building on our integrations because we consider ourselves the channel manager, everything in-product you can manage through Chameleon. That way you have built-in clash management, frequency capping, alerting to what's happening, analysis, etc. We’re trying to extend more in some of those areas of what else is possible in-app through other experiences.

We’re very much believers in a best-in-class approach. We build the thing that we want to be the best at and be really deep with. We don't want to build product analytics and visualization of what's happening in the product, click tracking, or road mapping tools that Pendo has. That's a broad, horizontal solution.

You can make a bet that in times of economic crisis, people tend to reduce cost and go with all-in-one, which might be slightly cheaper than building best-in-class. But the thing to think about, also for buyers and decision makers, is whether something is a revenue center or a cost center.

If you think that onboarding is a cost center where you just have to serve the purpose and minimize the cost associated with it, like maybe customer support, then you basically want to spend the least amount just to get the job done.

If you think of it as a revenue center, which sales often is, then you really want to invest in a best-in-class tooling, because any small benefit can lead to outsize return. That's why we believe that in this category, it's important for us to go deep, and be the best player in the space, versus build a broader solution.

Does that connect back to generation two versus generation three—that in generation two these are more broad-based all-in-ones, and generation three is trying to niche down on something super specific and turn it into a revenue driver?

I don't know if one drives the other, but it's definitely coincidentally that's the way. And maybe it's because when the likes of Pendo was founded, it wasn't as easy to be a niche player. But yes, now I think our approach for sure is not to go broad, but to go deep. It remains to be seen how much traction, if you go even more niche, can be built. Can you build a big company just doing notifications API? Unclear to me.

Can you talk about the Chameleon pricing model? What do you see as the pros and cons of your usage-based pricing model?. What kind of opportunities do you see for business model disruption similar to when Amplitude or Heap came along and gave away the data points for free that other companies were monetizing.

I think the ideal is that you charge based on delivering value. If I knew that a user activating for a customer led to $5,000 of lifetime value, I'd love to be able to charge based on that.

Intercom recently launched a pricing model based on resolutions via their chatbot—we've tried using [their] resolutions, and it wasn't super accurate, but I think that's a good idea. It's a good idea to try and see if we can get closer to the value that we bring to a customer.

Currently, we use monthly tracked users, which is our model of the number of users your software has, and that’s what we price on. It kind of gets there, not all the way there, but I think it's better than company size. You used to have very opaque pricing—like, “Okay, your company is bigger than 300 people, hey, there's a different pricing sheet, we can't show it to you.”

I think it's much better than that kind of pricing. It also doesn't make sense for us to charge on seats as much—which is the other common pricing model—because we're solving for a product pain. It's not solving for an individual user pain, or it's not an individual user job to be done, it's a product job. We need to activate users. So that's why we've aligned to MTUs. There are costs and cons to that.

People sometimes don't know what their number of users are, or they find it hard to predict. People will ask us, “Okay, well can you give us a price for this number of MTUs? And let's assume we'll 5X in a year—can you give us a price for that?’

I'm like “Are you sure? You've been around for 10 years. I don't know if you're 5X-ing this year.”

It can be hard to predict. We did see Segment move to MTUs as well. So now it's becoming a bit of a standard. But why is it not free?

I think the reason that we don't have it free today is because there is a significant cost to serve, and that comes from someone installing code in their application.

Whenever you install code in their application, then it means that there's questions about whether something works, if it doesn't work, why doesn't it work? We have to dig into that, and sometimes log into their applications and check it out. We've stayed away from free, but we do have an upcoming free product.

Now, it's going to be slightly different and it's going to be interesting, and it'll take on a slightly different category, and expand it in a different way. I'm excited about that. But yeah, hopefully that'll be much lower cost to serve.

Can you talk a little bit about your upcoming free product?

It's a new product called HelpBar, and it's a bit of Command-K kind of functionality where you can search and navigate.

It came from real customer requests from us because—and this talks to the fuzziness of our category—people have really good knowledge bases. They’re like, “Well, half my knowledge is in that help center.” And we tell them, “Don't recreate that in product walkthroughs, just signpost it and link to it."’ So they're like, “Wait, can I get that into my product?”

What we did is we built this search bar which works a bit like Spotlight Search on Mac. It hooks up to your existing help center, and lets users search for any article or any content in that help center, but from inside of your product. On top of that, it delivers an answer by AI.

When they ask a question, it reads the documentation and gives them an answer in-app. Now, this solves the same problem, making it easy for users to onboard and learn software. It does it in a different way, and hopefully the cost of service is much lower. It's not about elements on the page, installation's straightforward. And so that's why we think that's going to be a good pre-product.

I'd love to hear about how you think about Chameleon’s positioning, particularly with respect to WalkMe, Pendo, Webfix app, and Queues?

Part of the way that we've been thinking about this is the focused approach. There's some specific differentiators that going deep rather than broad enables.

One is functionality and features that are really for end user delight. We don't want annoying pop ups. What are things that we think end users are going to appreciate? I'll give you two simple examples, or maybe three examples.

One is a time dismiss, which means that if a user doesn't engage with something, it'll just count down and automatically go away. The idea here is like ‘hey, if someone's seen something, they're not engaging, don't let them have a negative click by having to dismiss it.’ Another example is a smart trigger. This is where experiences will wait until a user is paused on the page before they appear. We look for ‘hey, is there a pause happening right now, has the mouse action stopped?’ It's not in the first flow, first session because they're busy doing something, but we've developed that as a way to be a smart delay. And the third thing is letting you just snooze stuff. It's like, ‘okay, hey, I want to snooze this. I don't want to get to it now.’ These are the three examples of features that others don't have, that we're trying to invest in because we want the end user experience to be great. So that's one.

The second thing is giving customers real advanced control and confidence when you're deploying lots of experiences across your product user experience. You've got a bunch of micro surveys running, you've got a few different checklists for different user groups, you've got some announcements, you've got a set of walkthroughs, how do you control all that? It gets hairy. There's features like very detailed rate-limiting, meaning that you can set different frequency caps for different groups of users. You could say, ‘hey, for my new users, don't show them anything at all.’ Or ‘for this group of users, show them something at this frequency,’ and you can get pretty detailed. Or for this group of experiences, for promotional experiences, only show those once per month.

Something else is alerts. We can automatically trigger a Slack alert when something hasn't been seen for a certain period of time. There's examples of features that are giving people really control. So that's control and confidence.

Then the third thing is the integrations. I talked about the extensions doing much more in your product beyond just the data integrations. Those are three key differentiators. Of course, we like to throw a bonus one in which is we're a good user experience, easy to use, nice people, we try to give you best practices, we try to partner with you. So hopefully that comes through—just the ease of doing business with us.

One of the things that you mentioned with generation three is that some of these products have deeper integration of code, where you might actually use their SDK in the backend. Do you have a perspective on that, like you don't want to be there or that you do want to be there, and are you willing to go there to enable deeper functionality? How do you think about that?

Maybe all three of the ones I referenced all require more code work than we do. So whether it's, every time you have to deploy something you have to change some code, and it's really like, “Okay, you are assuming there's an engineer available for this purpose,” whereas we've always come back with it like, “Let's assume there's not.”

The ultimate goal is that it just needs to look and feel native. That's the goal. It doesn't matter how you get there, whether you require engineering or don't, but it needs to look like it's a core part of the user experience. Those are some of the challenges of Gen-2 products—they feel disjointed or they don't appear, they're unreliable, they look clunky.

We've enabled some embedded stuff already, you can embed stuff into the page, into the DOM. We're trying to do more of that, but we're still going at it with the perspective of low code. The simple solution is, “Okay, just hand it off to your engineers.” But then that goes away from the original premise, which is, “Now it's just part of my product development process. I need to QA it, ship it in the same way, I have to wait.” The goal is, can we get to the same ultimate end of being native and controllable and correct and reliable without needing code? We're trying to get there in our own way.

There's so many adjacent categories and products here, and a lot of these questions touch on that. How do you think about the boundary between user onboarding and in-app messaging? Marketing automation tools like Intercom and Customer.io—some of them do have product walkthroughs, user journey stuff—do customers use one or the other or do they tend to use both?

What we've seen is that this category is something that needs depth. You can't get away with a surface-level offering because ultimately people are like, “I want this functionality and if it doesn't work, well, it's not going to work for me.”

Intercom is a great example. Intercom has, maybe had, a product tours offering, and they've deprioritized it. It's a big company, it's a good product company. They ship a lot of stuff. They went hard at it, but it wasn't successful as a product. It's not even on their website now. You can't even find it if you're trying to find it. That goes to show that if you want to go broad, it can be really challenging to build something that works well and tells us that this actually is a category in itself.

Now, it's still a new category, which is why it doesn't have the same gravitas as a product analytics category or an ETL category, but that will come in time as long as we can crack the problem. But yeah, there are a lot of adjacencies. In-app messaging or emailing is similar to customer communication. You've got the help center, and ticketing, and chat is similar. Mobile is parallel and mobile notifications in-app. There are a bunch of different categories, what we do is try to integrate as deeply as we can with everything else. For Intercom, from a Chameleon experience, you can launch Intercom Messenger from it.

With Customer.io, you can trigger an email based on someone clicking a button. You give them a prompt like, “Hey, we have a new report, would you like details?” They say yes, and that can fire an email. There are ways to put it together.

It does require a little bit of sophistication from the team or product or person managing it. Over time, we're trying to get more and more native with that, and so it gets easier and easier with those integrations. But it doesn't seem like there's been a successful example of a broad solution doing this even with Pendo, they're not necessarily killing it in this category.

How do you think about whether Chameleon is for product marketers, product managers, product designers, or some other role? What is the landscape for those types of products? It's a relatively recent phenomenon that product people, for example, have had products targeted towards them.

Part of the problem is PLG—organizations are still catching up to the new way of running or the better end user experience.

We have a whole variety of companies where, in some cases it's a growth PM that's responsible for activation, engagement, monetization, in some cases it's every PM is responsible for engagement on their own feature, in some cases product marketing is responsible for driving awareness and adoption, and in some cases there's a customer marketing element, in some cases it's customer success teams that are responsible for adoption.

Unfortunately, there’s a bit of a gamut of roles that we end up serving. Predominantly, it's people responsible for activation and engagement, retention of users through a tech touch or self-serve manner. Often, of course, that's product managers.

Regarding tools for product managers, there's been so many.

Linear is the new darling, but we don't think that we want to be that one suite for all PMs. It's almost like, I don't think if someone was trying to build software, someone wants to build a Salesforce today.

Back in the day, Salesforce became the suite for salespeople, you do everything in it. I remember even Pendo talking about that as a perspective—they want to be the suite for product people. I think product people are too savvy to use an average tool that sits across multiple categories. The demands for a consolidation of tooling comes from procurement, finance, leadership, etc. I think product people would be happy to use great tools in whatever they do. We don’t have any expectations to try and do an all-in-one solution.

AI has proven really effective during onboarding because you can create these magical experiences—see Gamma or Tome—where you just type things out in natural language and then it can pre-populate a document or slide. How do you think about incorporating AI into Chameleon to enable these kinds of magical onboarding experiences, and how do you think that this might change the user onboarding category?

I'll talk about how it affects the category and the workflow first, and then I'll talk about what we're doing with AI.

Right now, AI is still mostly rooted in chat: you ask something in natural language, you get a response. That has great potential to speed things up, but I think you won't get away from interfaces being needed where you present information in a more visual way.

Obviously, with data and analytics, trying to figure that out in a chat interface is hard. A graph is much better. There will be lots of aspects that will be better as visuals. The conversational interfaces can help support that or bridge the time to get there.

We've already introduced this idea of being able to ask a question in the HelpBar and get an AI-generated response. We're now thinking about what's the next level from that.

Can we give people a walkthrough or can we point them to the right place to do that? It's still a leap to automatically create walkthroughs or guidance with AI. It's almost like that's one step before just creating a product itself with AI, which I don't think we're there yet. It requires a lot of contextual understanding that we don't have, but we're trying to find ways to involve that. I talked about the smart trigger, knowing when someone's pausing on a page.

Over time, we expect the analytics tools or those that look at user data to be able to auto-generate segments of users like, at-risk users, these could sync to Chameleon and therefore you can automatically target the right users. That's an aspect of AI that we think could be valuable.

We've already added the standard things, like improved copy with AI. A cool thing you can do is also put in a help article and we'll automatically summarize that for a tooltip, for example, so it makes that building process easier. We're thinking about how to maybe do that at scale. And we're going to be adding the ability to summarize your micro survey responses to get a quick understanding of what people are saying.

For us, AI is a technology that straddles all of the different things that we're doing. Where can we introduce it to make it better? We've got automatically generated titles for checklists if you add a walkthrough. There's lots of different places that we've introduced it, we've been working on it, we continue to work on it, but I don't think it's yet in a position where it's going to create a structural change in the need for a solution like Chameleon, where everything becomes chat and there's no interface. We’re still bullish on the need for interfaces and the need for personalized interfaces for users.

One of the interesting things about this conversation is that a core thesis today of B2B and SaaS companies is this idea of going multi-products all-in-one, colonizing everything that X role needs. One of the things that we've been talking about is how Chameleon plays nice with many other tools, is best at user activation and helping generate revenue and this type of thing. Under these circumstances, what do we need to believe to believe that Chameleon is going to be a very big company, if not with a traditional SaaS all-in-one thesis?

There's a lot of scope for continuing innovation. This HelpBar interface is brand new. There's no tooling for this. It's not a standard category, but it in itself could be used by every product. We have plenty of ideas around ways to make your interfaces more personal, more dynamic, without requiring code or with low-code, that there's still a lot of value to provide companies, and there's a lot of value to tap into. Our approach isn't like ‘oh look, here are six existing categories that are parallel or analogous to our product, let's chase after that.’ Our job is, how do we innovate further in things that people are having problems with or want to solve for, but no one's built product for it yet. That's how we think about it.

The patterns come and go. We don't want to be a product tours company. That's not what we're trying to do. The product tour is a moment in time. That's one way to solve it for now, but the goal is, how do we provide personalized user experiences at scale without requiring engineering?

In terms of the CommandBar and some of these other things, how do you pick and choose between things that you think are durable, things that you want to enable versus trends that are a moment in time?

That's a good question. It's almost like there's nothing that's permanent. Everything is transient and impermanent. The goal isn’t to pick something that's forever lasting. The goal is to pick something that will provide value to companies in our customer demographic in the next three to five years.

We also typically tend to wait for some traction. You have the super early adopters that built stuff—Slack is a good example. They built this Command-K functionality, and they were probably among the first to do it, they made the K the thing that you have to do.

But has anyone else already implemented that? Well, when you start to see some other companies implement it, when you start to see a product spring up to target that, then you see there's validation in it.

There's another example. We didn't talk about Sprig micro surveys. It's very focused on microsurveys, but that shows validation to that part of the product. That gives us confidence around building that stuff. We announced it [the HelpBar] less than a year ago, so we've had intentions around it for some time and I think it's going to stick around, the search interface. So we'll see, who knows? It's evolving.

If everything goes right for Chameleon over the next five years, what has it become and how is the world different as a result?

What I would imagine is you and I log into a piece of software and it looks very different to each of us.

Today, we both log into a piece of software, sign up, it's going to look exactly the same, pretty much. It's the same architecture, same framework. It doesn't take into account where we came from, what was our journey to get to that point, what might our intention be?

The goal and expectation for us is to have a world where software is truly personalized. Maybe the speech is hidden for me because I don't need to worry about them in my first user experience and there's different ones for you, or maybe it's just that we're signposted to different ways of learning or whatever it is.

A world where software is much more personal, the user experience is much more dynamic and you can easily indicate, hopefully, what you care about and what you want.

Chameleon would power a lot of that UX personalization and enable you to have really dynamic software that doesn't need a ton of engineers working on all the different versions and flows and all that kind of stuff. That's what I imagine the world to be, and hopefully we can support some of that.

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.