Product & Customer Success lessons for Companies of Any Size with Dataiku CCO + Lead of CS

Dataiku's Kurt and Jake explain how to grow from pilot users to company-wide adoption by mapping stakeholders across three levels (users, managers, executives) and balancing structured processes with flexible field work. They use a global bank case study to show concrete tactics: account mapping, operating-model analysis, ROI quantification, and hybrid enablement programs.
Chapters
Today we're going to be speaking to you about the 1000x chasm. You know, for us, it's really important at Dataiku to think about the way in which we're supporting our customers and really, let's say, building the internal structure to do that at scale. And so what we want to do in this talk is really challenge your thinking. I, and I think that the way that we'd like to do that would be first to challenge you to think about how big your market actually is. Obviously, there's many different calculations out there, many different ways in which different financial analysts, investors, your own teams may be thinking about your total addressable market. There's a lot of that that has to do with the positioning of your product. But what we'd like you to think about is how could your customer success approach allow you to unlock potentially vastly more market opportunity? At Dataiku, our experience has been that there has been a much greater potential than perhaps we originally realized, and a A lot of the access to that potential is through customer success. And so that's been an extremely informative experience for us at Dataiku. And so we're hoping to share that experience with, with all of you today, because we do think that if you do customer success in the right way, that there might be far more market out there for you, which doesn't require a massive pivot, which doesn't require you to change fundamentally your, your product. It may just be a matter of changing the way in which you engage with your customers, the way that you organize yourself internally, and of course, the way in which you think about the way that those two interact, your internal organization feeding into a, into the customer experience that you want to have. The underlying theme here, though, is going to be one that we think about a lot at Dediku, which is, which is tension. What are the inherent tensions in a lot of these processes? And we think that it's actually not by running from tension, not running from things which may seem on the face contradictory, but rather embracing them, that you're going to have the most success. That you're going to be able to balance the various challenges that you need to in order to succeed in your market and of course become the dominant market player that you all hope to be. So that's going to be an underlying theme throughout all of this talk as we go through the different examples and so on. So look out for that word tension. For us, we really do think it's at the core of your success. It certainly has been at the core of our success. So just to walk you quickly through our plan for the talk today, We'll do a little bit of an introduction on the next slide, so you know who we are and why, why it's been deemed appropriate for us to speak to you on these topics. Ultimately up to you to judge, but it'll be useful for you to understand who we are and where we're coming from. Then points 2 and 3 are 2 different concepts that we're then going to spend a little bit more time digging into. The first is the concept of nested value. Here we want to encourage you to think beyond just users and consider a broader, let's say, group of we can call them stakeholders for, for want of a better term, within your organization that you need to satisfy. The third, or point number 3, the second of the 2 points that we want to, that we want to hit home, is that notion of tension. We're going to give some specific examples as well of when we lead into that tension at Dataiku. And then to wrap it all up, we're going to talk about building a bridge across the 1000x chasm, right? How do you actually do this in purpose, in practice? And what are the main takeaways for you to walk away from with, from from this talk. As we said, as Caitlin said at the outset, we do have 20 minutes set aside for, for questions at the end. So please don't hesitate to, to use that to your full advantage. You know, we're here for you during this, during this session. So we really look forward to those questions. Feel free to drop them in the Q&A module. We'll get to those once we, once we wrap up. But first, who are we? Who is Dataiku? Let's start with who is Dataiku first, and then we'll introduce ourselves. But Dataiku is an enterprise AI platform. And so our customers, and it's relevant for you to know who we are and, you know, and to think about, let's say, the way in which we've built our teams or the type of customers that we serve, because of course, that informs our, our perspective on how to serve those customers. Our customers do tend to be enterprise, large enterprise customers, you know, where we typically are working on a 1 to 3, 1 to 3 year contracts with, with our customers, and typically at larger dollar amounts. That said, we're also going, you know, really attacking the, the SMB market as well, leading to this need to, to really be able to cross that chasm. Between small customers and large customers, but also small entities within larger customers, as well as, of course, the, the top of that pyramid as well. At Dataiku, I'm the Chief Customer Officer, which means I have responsibility for our customer success and professional services organizations for all of our customers and all of our teams around the world. And today I'm joined by my colleague Jake, one of my favorite colleagues. Don't tell the others who leads our customer success practice in Canada in the US East. Jag, would you like to say a few words of introduction?
Yes, thanks so much, Kurt. So yes, as Kurt mentioned, I lead our team in the East and in Canada, and I actually think that I have the best job in the entire world. I'm able to work with people, I'm able to help them solve problems with technology, and I'm able to travel all over North America. So it's been a really beautiful journey, and we're going to talk a little bit about this, but I've really loved how our organization has found new ways to engage with customers over these last 18, 18 months. And while it's lovely that we're back in person again, it's great to see how we've leveraged technology to continue to drive value for our customers. So thanks so much for having us today.
So let's, let's dig into that first topic, thinking about nested value. And the way that, again, I'm framing that is going beyond users. I think it's natural for any sort of product company, any sort of software company, to really think about the user experience. Natural. It's essential, you have to do it. But I think that sometimes as an organization where, you know, your goal is to deliver value to your customer organizations, sometimes we focus almost too narrowly on that user, on that individual, which once again, we have to get that right. You have to work with your product teams, you have to work with, with your engineering teams to ensure that the product is meeting the user's needs. But we want to expand your thinking, right? We want to make sure that you are thinking about the ways in which the value that you deliver for your customers is nested. And what we're talking about about there is that there's different, you know, levels within your organization, even those that are not users of your, of your platform, but who have needs. And we can think about this almost as a, as a pyramid, as a hierarchy, where at the base, right, you have all the individual users who, you know, throughout their day are using your product, right. And of course, that's where the core UX concerns come in, maybe they're focused, you know, and so we want to make sure that they're getting value that value for them. It might be any number of different things. You know, probably comes through some sense of efficiency, some sense of mastery, some sense of growth, right? Thanks to, thanks to this great new technology, I'm able to do things that I wasn't able to previously. That's good for my career. You know, I'm having impact on my, on my company. And I enjoy the interface that I work in all day, right? There's those core individual needs, which absolutely are the foundation. But then it's important to think up that pyramid as well, What are the needs of, of that team? And for example, the, the manager level, what do they need to accomplish? And how can you as a product company understand the needs of that manager, even if they're not directly a user of your platform, articulate that need, or articulate that value with them and ensure that you're consistently delivering on that. And then similarly, right, let's continue up the pyramid. Ultimately, right, there's then the organizational needs, the, the executive or corporate needs that, that come along with that. And this is where, you know, you start getting into topics related to transformation, topics related to the strategic orientation of the, of your customer's organization. Now, of course, not every product is necessarily suited to have those discussions. Not every product is, nor is that not every product, you know, really focused on individual needs, right? You all have your individual or your specific go-to-market strategies. But at Dataiku, we found quite a lot of success in thinking about these 3 different levels. Of course, sometimes there's multiple levels within there, then you need to multiply this across different roles and the, you know, the lines of business. You know, for us, it's, you know, we have the hierarchy of data scientists within our customer organizations, but then you have the business units as well. How do they interact? There is some complexity there, but by embracing that complexity and, you know, really ensuring that you're driving value to those different levels, that's where, at least in our experience, there is a lot of potential and a lot of real growth opportunities for your organization that you may not— may have not realized previously. Now I can sit here and talk about the theoretical aspects over modified images of pyramids, but I think it's more valuable actually that we take this and we make it very concrete for you. So this is where I'd like to invite Jag back in to speak to a real customer experience that we've had working through these concepts. So Jag, over to you.
Thank you. So yes, as Kurt mentioned, we worked with a major global banking customer of ours, and the stakeholders were really diverse. 4 different groups across different ends of the business, starting with IT admins, cloud architects, their data center of excellence, and their business users. And within these teams, there were different levels as well, similar to the pyramid that Kurt just showed. So if we talk about the first team, the IT admins, it's really important across any stakeholder to really understand what their goal is in order to understand what value means to them, right? Because at the end of the day, value is achieving your goals. So we learned that this team had a huge mandate. They had to, they had to find a way to really gain some efficiencies in their data pipelines so that they could move their models out to production as fast as possible. But they had to do it in a way that was cost-effective. And so we sat down with them and we said, you know, let's look at your pipelines. What are the areas that are really costing you a lot of money and the ones that are taking up the most amount of time? And let's start quantifying what these issues are. And we were able to redesign their process, introduce some efficiencies with our offering. And the end goal was they were able to find a path to achieve their goals, but also find the language and the metrics and the numbers to go to their executive stakeholders and say, this is the investment that we need. And in making this investment, this is the value we're going to realize right away. And in the end, we can achieve our goals, but we can do it— we can do it in a way that's cost-effective and gets us there in a really fast way. Then we started talking to the cloud architects. And the cloud architects had a mandate to take their existing on-premise environment and move it into the cloud so that they could really advance along the technology curve. But their big fear and big challenge was they didn't want to have to get into more vendor relationships. They wanted to find a way to minimize the numbers of vendors that they worked with so that their end users would have a more seamless experience, and they could simplify the way that they service their business teams. So to them, simplicity, a smooth transition, and a strong user experience was really important. And you know what? Articulating which product features, you know, align with their goals was super easy. We know we have a good product. We know we're going to be able to achieve success. So we could talk about, you know, a consistent interface or being cloud agnostic. But here where we really added value was speaking to the execs and saying, you know, cloud is just the first step. But here's the industry expertise that we're bringing, and here are the patterns and the challenges that we've seen. So have you thought about the fact that maybe your cloud strategy will change, and you'll realize this isn't the right platform for you? And here's how we're going to go on that journey with you and help you be more flexible and really future-proof your solution. Or, you know, you're a big investment bank, and we work with lots of banks. Did you think about the fact that some of your teams won't be able to move everything onto the cloud? So let's also think about a hybrid approach, right, where we still make it super super simple for you. We still create a great user experience, but again, we offer this flexibility. So of course, value for them, you know, they had a vision of what they thought value was, but we were able to articulate new changes that could come up and new ways that we could really simplify their process to move on to the cloud. Now, similarly, their Data Center of Excellence had a similar mandate, and these executives had this huge mandate to unleash AI and machine learning across the organization. Their goal was, how do we really achieve success by making us a data-driven organization, upskilling our people, and moving along the AI maturity curve? And also, their big concern was, how do we create a seamless experience for our users, right? How do they get off these legacy tools and still like our tool? And so again, we were able to highlight a roadmap of how we'd help them with this change management, how we would upskill, but really, what does this mean for their organization? You know, what is the power— what, what is the What are the net gains that are going to come out of the power of each individual, individual user now being able to make data-driven decisions? What's the power of different users from different ends of the business being able to work together in the same spot? And what will they gain in their industry? And what will they gain in being able to move along the analytics maturity curve? And then we were also able to estimate the value and the business business impact, right? So what efficiencies could they gain? How could they repurpose their people to do more insightful work instead of doing a lot of the manual data prep work? And then, you know, I know we talked about stakeholders being in different ends of the organization, but those business-level users were really important as well. And so we invested a lot of time and energy in connecting with our business users and really seeing what success looked like for them. We knew what those organizational-level goals were to really, you know, create efficiencies, unleash AI and ML, but what did what do those end users really need to have a good experience with our tool? And so investing in those relationships, we learned that they had a lot of regulatory issues they were dealing, dealing with. And some of our features were, were helping them get there, but kind of missing the mark, and it still created a lot of manual work for them. So we sat down and we listened, we talked about our product roadmap, we talked about what they needed to see. And in total to date, I think we've created close to 100 feature requests for them. And so in working with them, we realized that value really meant being able to have their voice heard, being able to gain insight into a product roadmap, but also influence it, which was something they hadn't experienced with other vendors before. And so that was a great key win, and that was a great way for us to learn even more about the customer. And so yeah, that was it. Over to you, Curt.
Thanks so much, Jag. No, and I really appreciate this anecdote, this story from a customer that I know well and is certainly succeeding. And I think in large part, is due to the fact that we were able to articulate that value, not just to the end users, right, though of course we were doing that as well, but truly to those who would benefit from the product's use by others in the organization, which I think is the essential step that we're encouraging you to make, is to think about who are the other beneficiaries within the organization, even if they are not users themselves or managers, direct managers of users. And that's exactly what, what you heard Jack describe here when We're talking to cloud architects, for example. Some of them may touch our product from time to time, but that's not ultimately what we were, what we were selling them on. They weren't being sold as users, or they weren't understanding them as users, but rather as stakeholders, as beneficiaries of that use by others. In building that complete understanding and working up and down in that pyramid, thanks to Jack's good work and the good work of the rest of the team, has of course allowed that customer to become one of our most successful worldwide. So also thank you, Jack, for all the good work on that account. Let's move on to the, to the next high-level concept that we want to talk about today. That is structure and flexibility and embracing the core tension in your organization. So once again, we keep coming back to that concept of tension. And here, one of the tensions that I really want to lean into is about structure versus flexibility. Once again, it can seem as if we're talking about two things, two concepts which are in opposition to one another. And of course, in a sense, they are, but that opposition is not a problem. Rather, it's a source of strength. 'Cause ultimately you need both, right? You need flexibility to ensure that your customer success managers, your practitioners out in the field working with your customers, that they feel empowered to develop creative new ideas for the customers. I like to think about a concept of, let's call it managerial humility, right? Where sure, you know, some of us have been doing this longer than those in the field. You know, maybe we have the benefit of seeing other customers over the years, but we're not down there in the trenches every day. And we don't know the details. We haven't been having the conversations that those colleagues are having. And I think it's really important for managers and those of you who are thinking about structuring your teams to acknowledge the limits of what, you know, what good ideas you can come up with. And so you want to build systems that allow for that flexibility to be able to capture those good ideas as they come back. But at the same time, of course, you don't want everybody reinventing the wheel, and that's where structure comes in. You don't want everybody to start, you know, coming up with their own customer success methodology analogy for every new customer, right? That's perfectly inefficient and probably leads to, you know, very inconsistent customer experience and all sorts of excessive costs on your side as well. You know, instead you want to equip them with a system with clear guidelines, clear expectations, and of course the assets, you know, the slide decks and, you know, some scripts maybe that they can work off of. Ideally a customer journey that they can look to follow to allow themselves to, to get into it so that they can apprehend exactly what it is that, you know, you are doing as a, as a product, the value that you're delivering to the different levels of that, of that pyramid, so that they can get that level of mastery where then they become those creative people coming up with, you know, good ideas that are relevant because they understand your company, you know, the actual software provider, they understand your business and your product and what can be done. And at the same time, they really understand their customer as as well. So you need that strength in certain places, but then you need to ensure that there is flexibility. That I will say that customer success as a practice, my perspective is it often it tends a little bit too far towards structure, towards repeatable processes. Now, of course, we're working in an enterprise software environment where we can afford to spend a good amount of time with each and every customer, where you, for the most part, we don't do a sort of tech touch or light touch. I think in those contexts, obviously, automation, you know, systemization of your, of your processes make perfect sense. But I worry that some of those practices creep up into some of the, let's say, more enterprise engagements. And that can really stifle creativity. Once again, you're generally paying your customer success professionals quite well. They should be experts in their, in their field, experts on your product, and really lean into their creativity and their good ideas, you know, truly embrace that tension of having a well-structured process for people to come onboard to ensure essentially, you know, the, the core activities are done, but then leave space for that, for that creativity to, to take hold. So once again, I don't want to sit here and, you know, share theoretical ideas now with pictures of willows off to the side there. Let me hand it over to Jag to share with you some, some examples of how that's actually played out in the field.
Yeah, absolutely. Thanks, Kurt. So one of the things we've actually been working over successive years to really define KPIs for our team, but the one thing that stayed consistent is that we expect every single CSM to have a success plan on every single account. And much like Kurt mentioned, sometimes it's really daunting to start off, right, with a new engagement or a new customer and determine where to start. And so when CSMs say, you know, what does a good success plan look like? I like to say it's a way to really tell the story of your customer and really know your know your customer. And much, much to Kurt's point, we're hiring really experienced, smart people, and we're paying them well, we're paying them for their creativity and that autonomy. But a few things have helped me with my team and really defining what it looks like to know your customer. Now the first is an account map. And when Kurt was talking about tension, I was thinking about this right away, because an account map is a really, really lengthy process to go through. What I often say to my team is map out all of our stakeholders, whether they're executive, whether they're users, and where they fit in the organization in terms of hierarchy. You know, how do they report up to the CEO, but also where do they sit laterally in terms of business units as well? And this helps us really visualize where we are in the account, but also where we need to be, right? What are other teams that potentially could have users that we could work with? A big aha moment for me was I was tasked with mapping out a really successful customer of mine. They had high adoption. We had executive support, very good organic growth. And so when I was tasked to spend half a day mapping out this account, I thought, well, this is a boondoggle of an exercise because I know they're doing a good job. I don't need to do this. When I took a step back and looked at this entire map, I realized two things. The first was that all of our executive stakeholders were actually at the director and senior director level. So although they had influence, you know, throughout the org and had helped us grow really well, they really weren't at that super high executive level that we expected for a strategic account. The second thing we found out was that of all of our executive champions, only one of them had a mandate to design the AI strategy of the bank. And so if that person were to leave or if their mandate were to change, we'd be in a really precarious position. So that was a point for us to take a step back and really start mitigating the risk before it became a risk. Start asking for executive business reviews, getting access to senior leaders, and making sure that we're not single-threaded. We're able to look at the entire entire account. And then after building out the account map, one thing that we ask our CSMs to do is really understand the operating model. And that means figuring out, you know, where does the economic power sit in the organization, and who designs the strategy, and how is it rolled out throughout. We've actually offered some really interesting trainings on different operating models, whether they're centralized, decentralized, hub and spoke. And we encourage a lot of knowledge sharing throughout the team as well on different operating models and how they've worked. The reason this is important is that it helps your CSMs understand how should they be engaging with this account, which team should they be connecting with, with which frequency, and also going back to our value discussion, understanding, understanding the operating model also helps us understand the language with which we speak to all these teams and all these different stakeholders. The next thing that's really important for our team to do is really understand the surrounding tech ecosystem. right? It's highly unlikely that your offering is just existing in a silo somewhere and isn't connecting to anything else. It's important to understand the ecosystem in which your users are using the tool. What other dependencies does your tool rely on? And it helps make sure that the environment in which your tool is operating is really set up for success, especially for us when, when often we'll have an environment that can't sustain growth, right? And we didn't have access or the insight into how the environment was currently set up. Set up. But it can also help create opportunities. You know, earlier we were talking about cloud offerings. If we find out that they're moving to the cloud, we can embed ourselves in those conversations and say, hey, here's the best way to do it. Because one of the worst things that can happen in a lot of these situations is that something completely outside of your offering and something completely outside of your tool could impact your user's experience, and you might not know anything about it, and you run the risk of a a bad experience or a bad brand and someone thinking this has to do with your offering. And then finally, all of this knowing your customer and all of these data points feed into really understanding the goals of the customer. And this, I'm a Canadian, so hockey is really important to us. So I was hoping to get some animation that said like, goal. But really in knowing where your customers are and who they sit, how they work together and what their surrounding ecosystem looks like, you can figure out what their goals really are as an organization as you work with them. Them. And when you know their goals, you know what success looks like, you know what value looks like, and you can start building— your CSMs can start building out these work streams to really help achieve those goals and achieve that success so that your customer comes back and says, not only do I want to renew for another gazillion years, but I want to expand your footprint throughout because you're really, really— you really know us really well. You're really a stakeholder in our success. And that was all. Back to you, Curt.
Thank you so much, Jake. No, no, I'm really looking forward to those gazillion-year renewals. That's going to look great on That's going to look great for our reporting. No, but I think that this is a really useful example and is really core to the structure that we provide to the organization. These are things that are must-dos. We know that every single account needs this to be done. We know that this mapping that, that Jag is describing is absolutely necessary to allow for a good outcome. But at the same time, right, we don't pretend that we know everything, that every process is perfect, and, you know, every aspect of our our offering is perfect as well. And that's where, you know, we have some good examples of situations where feedback has come from the field, from both our users but also our CSNs out in the field. And we've been flexible enough to adapt to that. So once again, Jag being the actual field-oriented experience person here, I would like you to come back and share perhaps one of those experiences as well from from the team?
Yeah, absolutely. So in our business, you know, we're measured— success is measured by adoption on our team, right? Are people logging into the tool? Are they using the tool? And are they using it regularly? And in order for people— in order for users to use the tool in the best way possible, they need to be trained and enabled on it. And so over the last 18 months, we've really made some, some key changes in how we train and enable our and the first, the first change came, I would say, early in 2020. And I'm sure different data points contributed to this decision, but often I would have customers come to us and say, is there a way for users to just kind of log on somewhere and access a few tutorials or some quick start blogs or something like that on how to use your tool? And we did have some great resources in different centers, but under Kurt's leadership, our user advocacy team was able to build out a portal that was a self-service learning portal portal. It's been beautifully defined with individual courses that can then be made up into learning paths. And after completing successive learning paths, our users could gain a certification. And the response from a lot of our customers, especially our large enterprise customers, was amazing. They said, we love this. We can just point our new users to this direction, tell them to go through it. Usually in about a week, they're up and running. And you've taken so much of the time and burden off of some of our champions to really have to go in and show these users how to use the tool. So it was fantastic. But then some of our users came back and they said, well, this is lovely, we love the online learning portal, but sometimes when new users want to get access to the tool, there's a lot of administrivia that slows the process down. So from the moment someone decides they want to use it or want to try it to when they actually get access, it can take a lot of time. Is there some sort of environment that we could just log into and test it out and play it out using fake dummy data? And we said, yeah, absolutely. Absolutely. We can do that for you. We can host an environment. However, in exchange, if you could just tell us what type of problems your users are working on, that helps us serve them even better and understand their usage even better. And so sure enough, with some of our customers, we've set up little private environments. We're the ones who bear the cost and really manage it, but we're gaining so much in return. They're having a great experience. They're able to use it as quick as possible. Once they eventually get access, they're able to hit the ground running because they already know how to use it, and they're sharing really useful information with us. They're saying, hey, this is what we hope to achieve. And we can say, hey, we can help you out with that. We can offer you some coaching on that use case. Most recently, some of our users came back and our client champions came back and they said, this is wonderful. We love this self-service platform, but sometimes we could use a little bit more. And we actually miss connecting with your data scientists and learning about their expertise. So is there somewhere in the middle that we can meet and build something that's more of a hybrid And we said, yes, absolutely. And so now we're deploying an entire enablement program where users will initially go through the online portal and our customer success managers, as well as client champions on their side, can go in and track everyone's progress. And then in tandem, we work with our client champion to come up with a really interesting use case, something that is complex enough that they can really see value and really highlight the key features of our tool, but something that's also simple enough that they can build a quick project in it. What we then do is we take the skills they learned in the online portal and then we do a hands-on training. We do it with their data, we do it in their environment, and we do it on a use case that's relevant to their day-to-day work. So they're walking away and seeing that, yeah, this is a great tool and I'm able to do interesting things, but this is how it relates to my world and this is the great stuff that I can create with it. So it's a much more relatable, much more valuable experience for our users. And they also get to interface with some of our subject matter experts and learn some some tips and tricks and best practices and really add a more personal and engaging approach to the training and enablement process. Back to you, Curt.
Thanks, Jake. And so once again, here's a— this is a perfect example of where, you know, a good idea came from our customers, translate, you know, transferred to us through, through the team members. We identified, yes, that makes sense. Now is the right time to do it. And we went ahead and got it done. And so I think that balancing the structure which is provided in the standard processes along with the flexibility to say, yes, as a matter of fact, we can do that. That's really key to your success as a customer success organization or as, you know, any sort of software business on a recurring revenue model. Those are the sort of actions that you need to be taking and the structures internally that you need to be building to succeed. So once again, public service announcement, don't hesitate to drop questions into the Q&A. A couple of great questions are already coming in and we will get to those in just a couple of minutes. But just before then, going to wrap things up, right. And what, what I want to tell you, what I want all of you to take home is this notion of strength from tension, right? That ultimately, by embracing these tensions between, you know, individual users and executive stakeholders, between structured process and flexibility in your processes, that embracing that tension is how you cross that chasm from, you know, an organization or a customer that may have only 2 users on your platform, all the way across to a customer that has 2,000 users on that platform. So crossing that 1000x chasm. So the metaphor that I often like to think about— I'm a person who often thinks in metaphors, mechanical, visual, and otherwise, right— is that of a bridge, right? We all know a bridge's strength comes from the exploitation of opposing forces. You have two things that are either pressing down on a keystone if it's an arch, right, or pulling in opposite directions if it's a suspension bridge, to ensure that that bridge is strong. Actually, without that tension, the bridge is not very strong at all. And so it's this dynamic tension that you need to seek out within your organization. And so ultimately, right, it's by building that bridge across that chasm that you're going to be able to exploit that much larger market that may be out there. And so those key takeaways that we want, that we want you to have. One is to expand your view beyond user, beyond users to all stakeholders, because it's not just ease of use or business value, it's both. And 2, to know that your team structure, your internal teams, need to be sufficiently structured, but also while creating space and building in space, engineering space into that structure for innovation, for flexibility. So you need to find the right balance between structure and flexibility. And ultimately, right, that's how you can cross that chasm from small organizations to large, to access those much larger potential user bases that you, that you may not otherwise have access to today, and truly succeed as a customer success organization that's driving value back to, to your organization. So with that, we want to say thank you for your attention, and we look forward to answering your questions. Actually, we've already got some questions coming in here, so I'm going to go ahead and turn off the screen share and we'll ask this first one. The first question is, how do you store, share, and collaborate on these success plans, or, you know, potentially other assets, I imagine, to actually track success against? We find that these activities are useful, but they often become static PowerPoints and PDFs. I have some thoughts on that, then, Jake, maybe you can add some, some additional detail. So for us, anything that is a must-do needs to go into the system of record. And for us, you know, that's our CRM, Salesforce, no surprise that it needs to be tracked there. In some cases, though, we do want to allow some flexibility in that structure. Remember what I just said, right? And we want to ensure that you can use a format which is appropriate. We do use Quip quite a lot, though it's not quite universal for those plans. In case cases where it's not something integrated directly into Salesforce, then of course we need a link to, you know, to our Google document to reference it. I think how you keep that from becoming stale and getting out of date is actually more through a management practice, which is when do you review it and in which forum. Because again, it's not just a matter of creating it, though the fact that the act of creating it is inherently useful as well. It forces the CSM to sit down and think about their organization and how they want to drive value to it. But really, it's when review it. And so, for example, we have, you know, some implementation risk assessments that we do for, for some of our bigger projects. And we now review those for our largest customers on a monthly cadence for the larger ones with a very broad group. Those documents also then get reviewed down at lower levels within the organization. And this can go all the way down to a one-to-one meeting between a manager and their direct report, where you may want to be going through those, reviewing those documents together. I think I have a kind of a general general belief that a document will go stale if it's not going to be the subject of a meeting at some point. And so it's actually by building that review in that you ensure that they, that they stay up to date. Jake, do you want to add on to that? You may have more, more relevant experience.
You know what, I was going to pretty much say exactly what you did around— like, I think leaders really hold our team members accountable for keeping this as a live document. And I think a way that we can do that is when we are seeking updates, setting the expectation that the success plan is a source of truth on the account. And if you ask a team member to go through this entire exercise, but you're never coming in to look at it or offer feedback, it is going to go stale. So, um, to Kurt's point, one of the things that's worked really well is when we are doing an account review or reviewing the status of an account, making sure that everything that we're asking of them is embedded into the plan. So we are constantly going back to this, um, to the same consistent document. But I do find centralizing things as much as possible and creating the tooling for your team that it's less of a manual ask and more of an automated or a frictionless ask is, is important. So for example, when it comes to building out account maps, we've adopted Lucidchart, which make it so easy, so user-friendly, and so intuitive to go in and create little changes. You don't have to create a new bubble and draw lines. You can literally to literally just click add or subtract to make new changes. So really finding ways to make these frictionless, but also holding your team accountable by referring back to this document regularly has helped me a lot.
And I— you saying that, Jake, makes me think as well that, you know, often we think from a management perspective, we're thinking, well, it's the responsibility of the, of the individual to, to keep that document up to date. And sure, that's true. But I think that there is a responsibility on management as well to actually look at those documents and make sure that people— well, that the team knows that those documents are being, are being looked at. You know, that's, you know, if I, you know, having done the job myself, right, I know just how futile it feels to be preparing something, pouring effort into something that, you know, is just serving, you know, either nobody's ever going to look at or is just to check a box. You can't have that. So I think it's really ensuring that everyone knows that this is a real document that everyone is going to look at, that, that's really important. So let me look back at the questions here. So just give me a brief moment to read this one, some of the questions which are coming in. Oh, this is an interesting one from anonymous attendee. Speaking of centralization, how do you typically land and expand? Second question, how do you manage the tension between fast-paced self-service business users and the CIO's antithetical resistance to shadow IT? Love that question, and not just for the use of antithetical, but extra points for that as well. And what does that sales motion and customer lifecycle look like? Okay, so plenty of stuff to work on here. So let's take them one by one. How do we typically land and expand? So we, we have a couple of different motions. We do have, you know, kind of a use case or business unit landing motion, right, where we're going in and looking to deliver specific value on one use case to, to a given customer, even a large organization. And then from there, right, it's going to be much more more of a— I don't want to say political, but an organizational build, right, where we want to take that success from this one business unit and then explain that to other business units or perhaps to a centralized entity so that they see the broader potential. Other versions, though, we, we do often come in with a large initial engagement sometimes. And what makes those different— those large engagements different is whether the full intended user base is already identified, you know, for example, this is a central entity and they've got, you know, hundreds or thousands of users and we need to go now and drive it down into them. Or if it's going to be, let's say, a sort of an internal reallocation of licenses, even with a reselling of a sort of an internal reselling of licenses, that changes very differently, significantly, how we, how we go about that, that engagement, because it's no longer, you know, a hierarchical top-down, we've bought this, therefore you must use it. It's rather, we have this available for you and you may use it if you want, which does change that, that motion. The second question was, how do we manage the tension between fast-paced self-service business users and the CIO's antithetical resistance to shadow IT? And that's where, you know, we, you know, I think that we, we sympathize a lot with, with that CIO. And we see a lot of value in our particular product case, and it may not be true for every product, but we do see a lot of value from our product product from a more centralized place. So often we're, we're going after and knocking on the door of the CIO very early on. Um, you know, other companies, and, you know, very understandably, uh, have a strategy of trying to fly under the radar for as long as possible until they can pop up, um, and say, hey, look at our footprint, you might as well, uh, you might as well talk about an ELA at this point. Um, that's never been Dataiku strategy, but again, I think that that's more specific to what our product does, uh, which again is not so much the topic for today than anything, you know, necessarily being the right or the wrong way to to do that. And then finally, what does that sales motion and customer lifecycle look like? Well, the sales motion, right, mostly it's enterprise. So it's, it's relatively long for most of our, most of our engagements, relatively long. We're talking on the order of months, though, of course, there have been some customers that we've talked to for over a year before they finally get around to buying the software. But ultimately, right, we do tend to have longer enterprise-scale sales motions during that sales motion. Importantly, and I think, you know, there's always ways that we can improve improve. But we do want to set the customer up for success during the sales motion. And that means ensuring that the customer has a good understanding not only of what the product does, but let's say what the mutual expectations are going to be between the customer and us for their success on that platform. And we take an approach where we want to do everything that we can to get them to a high level of value as quickly as possible. And so that involves professional services to help them get up and running, but at the same time be building towards their own autonomy, so that they can start taking on more of that work themselves. Our most successful, our largest customers are those that are able to onboard their users themselves. They do that in a highly contextualized way, onboarding, you know, their employees onto our product, but in a way which is specific to their organization, you know, they built out that, that capacity. And so I think that, you know, for us, it's, again, maybe specific to the, to the nature of our product or our, or our sales cycle. But we, we've generally found success success with those models. Jag, is there anything that you wanted to add on any one of those dimensions?
Yeah, to the question around landing and expanding, one of the things that our CSMs are measured on and really encouraged to do are develop customer champions, not just people who use the tool and have a really good use case, but someone who's really willing to be your voice within their organization or even externally. So we engage in a lot of joint webinars or success stories, or our community usually recently came out with an award, but really investing in those relationships so that your customer kind of is that driver of growth for you. And really the key to that is keeping the customer really happy, right, and delivering value to them. But we've had some really, really great success where we've had customers advocate as great champions for us, both internally internally and externally. And in terms of our customer lifecycle, one thing I really love about our practice, and one of the reasons I joined, is that we really consider customer success as a strategic stakeholder in the customer engagement, even before the customer becomes a customer. And we introduce our teams early on, and we introduce a lot of our post-sales teams early on, and there's never a hard handoff between, you know, post-sales— sorry, pre-sales to post-sales. Sales, there's always this overlap. So we're gaining a lot of knowledge on the customer relationship along the way. But there's no hard break where the customer says, okay, now I'm dealing with you. And now I'm dealing with you. It's kind of like, like a spectrum of different folks that they deal with. And I think one that creates a really seamless experience for them. But it also helps them visualize the future and engaging with us really early on. So before they even become a customer, they can start thinking about what are these enablement activities going to look like, what are these success planning activities going to look like, and, you know, build a relationship with us before it becomes a formal commercial one.
Exactly. Extremely well said. Thank you, Jag. And then I see one more question over in the chat, which is, how long did it take to build and launch your LMS platform? LMS is a learning management system, so it's the platform that we do the, the online trainings on for your enterprise clients with unique use cases. So let's see, if we roll back, we launched the kind of the LMS initiative in January of 2020. And the, you know, kind of the first, first version went live about 5 months after that, if I recall correctly, in May was when we, we formally launched what is academy.dataiku.com. And now, that was with a team of about 4 people, 5 people working on it full time, with a good amount of input from other teams though, as well, right. So there was a significant investment in that. We started with the generic, you know, one-size-fits-all content for everybody approach, you know, kind of building out what we knew to be the core curriculum for, for our product. And then it was, you know, once we got that initial version out, those initial courses out, that we started getting the feedback that, well, we need, you know, something a little bit more specific to users that are migrating over from this other, from this other product, or that we need to do something specific for, for individual customers. And so it was then later in 2020, through that crazy year, that we started started building some more of the custom content for the, for the teams. And, you know, right now with the team that we have today, you know, it'll take about a month or so to produce a new learning path if it's made for general consumption. If it's a matter of, you know, just adapting existing content and making it a little bit more relevant to a given customer, that can be done in a matter of days. That said, you know, this is not to— I would encourage all of you to not underestimate the, you know, kind of the time and effort required to make a really good learning experience for your, for your customers. You know, instructional design is a real skill and is a real craft that you need to hire for. We were lucky to have some really talented people already within the organization, but that we did have to go and hire for as well. But that said, the payoff is there, the value is there, and it's definitely worth the investment. Just don't underestimate what it's going to be. You may want to— you need to decide at what point in your growth and your maturity does it make sense to make that investment. But I guarantee you that the, that the value is there if you do a good enough job, right?
More from Jason

Why Your Next Hire Should Report to an AI, Tragedy Apps, and Too Many AI SDRs? | The Agents #004

Our Agents Drove Our Salesforce Bill Up 80%, Marketo Hates Agents, and We Stealth-Churned Off Notion

Managing 20+ AI Agents: Lazy Agents, Our $500K AI Bill, Stealth Churn & the Death of 60% Solutions







