Totango CEO Guy Nirpaz on how to scale in a predictable manner

Note: this is an automated transcription of our podcast interview. There will be some typos 🙂

Would you rather listen to the conversation? Listen to our podcast!

Today, I have the honor of interviewing Guy Nirpaz, the CEO of a great company Totango. Welcome!

Thank you. Happy to be here.

Yeah, thanks for joining. And to get started, maybe you can give a 30-second commercial on what you guys do and what the company is?

Sure. So, Totango is a leading provider of Customer Success Technology. We call this the shared customer OS and we help companies. I mean, the heart of the mission is to help companies retain and grow their customer base, maximizing renewals and upsells, and the overall implementation, improving the net revenue retention metric. But the way in which we do it is we allow companies to design and implement customer journeys that would lead to value, helping the customer have a great experience, which ultimately results in the financial outcomes we’ve described. We’ve got a wide range of customers for our freemium model from start-ups to the largest companies in the world like SAP, Google, Zoom, Microsoft, and others.

Okay, cool. And so what problem were you seeing in the markets that led you to start the company?

We started when the cloud took off and it was clear that the relationship between companies and their customers was changing, given the business model that is shifting more towards subscription and pay-per-use. So, all of a sudden, the vendor of the company had to make sure that their customers were getting value from the products and services they subscribe to. And that started this entire concept of customer success management. All the activities and initiatives the organization is doing to ensure customers are getting the value, the actual value from the products and services, and by not renewing and growing their subscription.

I guess that means that when companies adopt your product the churn is lower. What are some of the benefits they should be seeing?

So the high-level benefits are much higher product adoption, higher retention, and higher expansion. But what they learn as they implement Totango is that they need to treat the customer journey and the customer success program as a product, continuously iterating and building better experiences for their customers. The first version of the onboarding program is a good example:  it delivers at some level but then you get feedback from customers that it may have been too slow or did not meet their expectations. You roll out a new version that performs better and so on forth and so forth. And clearly this journey of optimizing the Customer Success Program never ends. And what we do, the technology that we provide, enables rapid iterations and execution.

And would you say that there is a general lack of professional onboarding within the business or is it a lack of tools?

It depends on the timing. I think initially people didn’t understand the need for customer success because the majority of companies were used to that that you’re done when you sell the product. That’s the traditional model. You sell the product. You get the money and recognize the revenue. 

So that was the first thing to realize that the point of sales or the point of subscription is just the first point. And then you’ve got to keep going and earn the customer’s trust every day. So, I think that was point 1. And then very quickly, it transitioned into ”What do I do right? So, how should I think about solving this?” Because if you are trying to resolve retention at the point of renewal, it’s too late for the most part. And that led to the thinking around the customer journey where you really need to design, build, and execute a much more intentional customer journey to get the outcomes you’re looking for. And that led to the recognition that the journey is long. Customers are different, of course. So you had to break the journey into steps. We call it the module success box and implement each iteration on each and every one of those separately just to make sure that you’re making progress faster.

Right. So that’s essentially triggered by the big switch of the one-time on-premise software to now we’re in a SaaS world. You typically sell small — initially you want to deploy to more users, but you also need the customer to be successful because otherwise, they’re just going to move out of your product. Is that right?

Yes, absolutely.

Very cool. And in terms of your company, for me, looking from the sidelines, Totango has been growing very rapidly and successfully. That must be a tough process as well?

Yeah. First, we were super fortunate that we are growing and seeing success: the fruits of our labor. So that’s super positive. But clearly, as you grow, you encounter challenges that did not exist before, whether it’s a customer base that is growing significantly or the number of teams and cooks in the kitchen, as I call it, to make every decision and move the business forward.

So in terms of you onboarding customers and your customer success, you’re probably using your own software to do that.

Absolutely.

So the process must have been fairly straightforward. But on the other hand, you also have the traditional divisions within the company that grow like let’s say your sales team. Did you have a process for that? 

Even if we used our own product the challenge with moving from a few onboarding projects every month to tens of one-product on-boarding projects every month is significantly different. And given that we are selling in a self-service motion premium, we cater to very small companies or startups with different requirements. So you also need to cater and customize according to the company’s needs. So not only the volume is different but also the segmentation of customers. 

If I look at the last two years, we’ve switched from a single onboarding program to four different onboarding programs. One is a complete self-service onboarding program for the customers who find this most effective. One is a group onboarding program, which we call the accelerator, in which companies onboard together at the same. They benefit from collaborating with other companies that are on-boarding at the same time with a designated and dedicated onboarding program to bigger onboarding initiatives and so forth. 

So clearly those multiple dimensions and analyses of process design are critical not just in the way we do onboarding or even customer success for existing customers and nurturing the renewal. It goes across the board. One of the things that has been helping us a lot is adopting an approach that’s very very customer journey oriented, even pre-sales,   from demand to intent to the opportunity to deal etc. because we’re looking at it from a very user-centric approach. So demand is a user searching for a solution to a problem, they sign up for the product, and get their solution. So, it’s a very personalized experience. And that involves delegating to the sales team and assessing the engineering team, among other factors. We could talk for a long time about this, but I’m sure it’s just the beginning of how to think about scaling.

So, it sounds like you created four different playbooks depending on the type of customer you’re dealing with.

We’re thinking about this more like versions of products. So, the first thing for us to really scale is thinking about the processes and the workflows as products. So revisions, backlogs, roadmaps, etc. It’s never like an end state of a process. And to optimize resources, we think about them as packages of the same product. So there’s a package that offers minimalistic features and then another package that has more features on top of it and so on and so forth. We have a build-up model versus four different distinct offerings that are very hard to maintain and there’s no cross-functional learning. 

And would you say it’s also a continuous iteration that based on what’s happening, you go back to what you created and then adapt it to the new realities to the new types of customers? 

Yes. So, as a product-led company, as a product-centered company, we’re committed to constantly ensuring that the majority of what we do is in the product. So the original customer success platform that we built has morphed into what we call Shared Customer OS and has more value in it. And then we are building scalable digital content on top of that, which is our success applications, we call them succesBLOCs. 

We’re pushing the people element of our team into much higher value activities.  We don’t want to be in the services business model. We’re in the technology business model and that works for us. So we want to create the maximum impact and maximum leverage from technology and digital content. But also we feel that once you put the team at the higher end of the consultancy versus service delivery scale, we get much better consistency in scale, which customers feel extremely positive about. So that’s our operating principle.  

Then we’ve got the core technology team that is building the product but we also have all the digital assets, which we treat as products as well. So, as I said, roadmaps, versions, and revisions, etc.. We also invest heavily in content creation teams, which creates content that is customer-facing but is also effective for our teams. 

We think that there’s good leverage in thinking about customers first. So, if we can create the customer-facing content first and then reuse it for onboarding our teams or training our teams, we get the benefit of starting from the customer and then using customer-centric language, which is super important for us.  And the content is mainly digital content and digital distribution with quick workflows for creating it, whether it’s playbooks or training videos, tutorials, or best practices.  We invest heavily in creating content and we’ve got teams that basically operate in that fashion.

I also noticed that working with Servoy that on the one hand, as a SaaS company, you want to be as much as you can as a technology provider and not a consultant. But on the other hand, to be successful as a SaaS company, if you’re not providing valuable content and insights, then your product loses a lot of value and you’re not sharing the best practices that you’re seeing across all the different customers.

Absolutely. The problem that you’re stating is absolutely correct because it’s about where your product ends and how do you complement it with more value. I think the market is not looking for how should I create, how should I start a meeting on Zoom or the content… the market is looking more for how should I run a meeting on Zoom or how should I run a more effective sales meeting, and so on and so forth? How should I run PR effectively, not how to schedule a QPR? So, what the market is looking for is the best practice. And the question becomes then how do you deliver the best practice? And we very intentionally chose to deliver best practices through the product. 

So, what the market is looking for is the best practice. And the question becomes then how do you deliver the best practice?

So, it has the scale. Obviously, you create one video, piece of content, or experience but the value is the iterations because if you treat that as a product, then you have a feedback mechanism. You can find out what’s working, what’s not working, how we can improve, what the next features should be? And you’re constantly improving the product. So, customers that participate in providing feedback are actually improving the best practices of the product for other customers as well. 

Through that, there’s this network of positive impact and agile dynamics. I think we had to deal with internal challenges as some people didn’t feel confident about that and there was an initial pause in the market. But once you get into the habit and prove that it works you get great reinforcing feedback. So, I think it can be done and committed to doing it.

Your software helps address this. It sounds like what one of my early clients at Servoy told me because we were doing a survey, as a development platform, but very, very technical, in-depth documentation. And one day one of my clients comes to me and he says your documentation is like the manual of an F-16 fighter jet. It tells me if you push this button, this happens. If you push this button, this happens. But it doesn’t tell me how to fly the plane. And I think that a lot of SaaS companies are missing out on that, when they’re looking at customer onboarding and customer success it’s really about how are you going to make your customers successful? And that’s not just through writing and documentation. It goes much further than that. Would you say that with software like yours, you also help customers to move away from the classic way of documenting and help files and walkthroughs, focusing much more on what the customer really needs to become successful?

The decision is going to be from a customer-first or customer-centered point of view. I think Steve Jobs said that you start with the customer experience and then you go back from there, you are making a whole set of different decisions. One of them is, of course, that you can’t operate in a silo. Right. Because that’s just customer success. Customer success is done by assigning a success manager for a customer. It’s done when the entire company’s product, success, marketing, and leadership are focused on understanding the customer’s needs and delivering them. It’s cross-functional. So the customer-centered point of view is, in my opinion, super important. 

When you realize that, you also recognize that you can’t have a siloed approach to delivery. If the content is in one system, execution is in another system, and reporting is in a third system, the information doesn’t flow fast enough to provide feedback for the people that need to use it. So they stop using it. And then you’ve got this rift: people are doing things from memory or being on-boarded by doing things that other people told them. And very, very quickly, you lose a lot of the core learning that you started with. 

So, I believe in single systems that have all the context and content in there. What to do, how to do it, and reporting on how it was done. It’s a new model, I think, in the enterprise architecture because we’ve all been used to the marketing cloud being separate from the sales cloud, which is separate from the service cloud, which is separate from the financial cloud, which is separate from the people cloud and the customer success cloud. I think the modern approach is shared infrastructure because there’s more horizontal versus vertical thinking about architecture.

So, would you say that more and more software should incorporate what you just mentioned and that your software is already doing that —not only how to do it but also the what to do and then also the transaction is stored somewhere. This has been done so that in retrospect, the things that have been happening in the company.

Yes, absolutely.

I do see that in a lack of a lot of traditional software. If you look at CRM systems for current CRM systems, they often talk about playbooks. If you look at the big players like Salesforce and HubSpot, they talk about playbooks, but they currently lack deep integration of those playbooks. And they only have the screens to do your work, but not the process of how are you going to get your customer to the next level?I agree. I think the architecture there’s a reason for that. You, for sure, have experience in that. There was this world pre-cloud that was called packaged applications. So it was like a big set of boxes for a certain transaction workflow, whether it’s supply chain ERP or customer relationship management. In any case, it was packaged ops and then transitioned to the cloud. But the cloud allows much more than that kind of sharing of information and workflow. It requires a much higher speed of execution, change management, and decision-making in this architecture where you just take the package to the app, put this on the cloud, and solve the problem.  I think it’s hitting its limits with companies’ need for fast decision-making processes. 

So, let’s say, the first solution for that was integrations. So, MuleSoft or Tableau and that’s kind of how Salesforce solves all these problems. They have separate clouds and a data information platform like Tableau to connect those things. And that’s good, it’s a short-term remedy, but it doesn’t solve the root problem where this architecture is a separated component architecture versus like a shared architecture model like CBP’s or Totango,. And I think we’re seeing a dramatic difference in speed of execution and decision-making. 

 The cycle of designing, reviewing, building, executing, learning, and building the next iteration is just too, too slow. And more and more organizations are realizing that they can’t continue to operate in this fashion given the market demands with the competition and pressure — competitive pressure two years of COVID and back to work and going back to hybrid and now this terrible war in Ukraine. The process needs to change. 

We think one thing has passed and the next thing comes along. So it’s quite disruptive for businesses.

So it’s clear that companies need to have the muscles and the capability to be agile as an organization. I think the architecture — the underlying supporting systems that drive those workflows and processes — needs to enable agility and quick cycle times, turnaround times, and continuous consideration. If we just want to see if what I’m saying makes sense or not, that just goes back 20 years in the way in which we developed software. Let’s look at what happens right now and we can see a sea of change from waterfall to Agile to cloud to DevOps. It happened in 2 hours. So that needs to be the exact same thing in business right. If I want to launch a new customer-facing workflow.L. And the organization is more than five people. Let’s say 100 people. 200 people in the organization distributed globally and you want it out in 24 hours. You’ve got to have a system that allows you to do that. And at the click of a button, you can’t have it defined in one place. The alignment model is just not fast enough.

I’ve learned a few things here. And in terms of scaling your own organization, what would you say were the biggest challenges in the past ten years or so in going from just a few people to knowing a few hundred people?

Number one is clearly talent, right. And the first thing in talent is hiring the right people for the right job at the right time. And then also making sure that those great people that you brought on board are actually rowing in the same direction toward the same goal and delivering. That’s number one. So hiring, onboarding folks, and getting more projects delivered. And then you get to the next level where you have too many projects that happen at the same time in the organization and then it’s about orchestration and synchronization of efforts. On the one hand, you want to create. You want to push down decisions and you want to delegate problems. But then there are a lot of problems being addressed at the same time, especially in a global organization, a distributed organization with people working from home, creating those sync points, collaboration, and coordination is super, super difficult. 

We found that the best solution for that is not only a lot of communication, using the right terminology and the right words but also documenting decisions in execution systems. Document the decision execution system, that’s the decision that is going to be executed. If you document in an email or in a Slack message or in a Word file like a Google Docs file and it’s not part of the execution, it’s much harder. And again, coming from a development background, these lessons have been learned years before. And if you look at how development is being done. It’s epic. And the story is in JIRA that is connected to the code. And you’ve got to comment in the code in the version that you’re creating that refers to the JIRA ticket. And JIRA ticket also has the test that verifies and validates that what was built was actually what was intended to be built. It’s never perfect. And it’s not easy. But it is clear that documentation is integration. And one of the advantages with code is that you can read it and you can understand what it does or you can run it and see what it does. And so there’s a closed loop to all the work that’s being done. I think we’re trying to mimic the exact same lessons in the rest of the business’s operations.

And that’s interesting because ten years ago I complained that the software business is behind the real world. If you look at construction, then in construction, there’s a clear separation between the architect and the person who’s building the software. Ten years ago, there seemed to be a lack of a very defined, proven process. And it feels like now, especially with Agile Scrum and the tools available — JIRA is a great example — that you’re giving where you begin with your epic, then you use the stories and start planning that software has been industrialized and now you’re taking these lessons learned in that area and applying them to the rest of an organization so that you can predict scale better. Is that right?

Yes. And so first, on your comment on separation from ten years ago, we could have argued ten years ago about what developers — do they really develop or design — or whether the compiler is actually the technical interpreter for the physical material? But we don’t need to go there. I think the lessons that have been learned are that you need to focus on measuring the outcome. 

One of the first things in the manifesto was that we value working software over the process in practice. It’s the work you start with — the deliverable and then you go back from there. But let’s take this as an example of how we apply this in customer success. So, do we do value retention or customer renewal or not? It’s critical, but it gives us an opportunity to learn from it. 

Even if a customer renewed their contract, it may be a difficult negotiation. What can we learn from that to improve the way in which we prepare a customer for renewal ahead of time? And then we need to go and implement downstream or upstream. So the outcome is still very super important but you really need to optimize the way you do things ahead of time. A lot of the insights that I can think of alluded to this idea where you want to maximize the chances of someone doing the right thing at the right moment based on past learnings. It needs to be documented and enforced at the point of execution. 

This is why it is important because if we learn something, we should do something in a certain way. How do we make sure that it’s actually happening faster? I mean, it could take its time, but if it happens faster then the learning is faster. And whether it works or not, we can understand and we can take corrective action or just reinforce and reiterate on that. So, this is how all these things are being tied together because you want to minimize the cycle time, you want to maximize the number of optimizations or improvements you can do at a given time. 

I remember several years ago talking to an executive that didn’t have a buy-in from their organization to buy a customer success technology. I asked him, so what’s your plan? And he said, in the next 18 months, I’m going to implement customer health. I told them, okay of course, with technology, you like Totango, you can do this in hours, not in 18 months. But how would you know? How would you know if your model is working? 18 months to implement the first version and then learn and then to implement the next version it’s another six months. It’s just not as effective as using technology. 

So, how do we do it? We are constantly on the lookout for technologies that help us accelerate. We declared war on spreadsheets. We declared war on presentations. We declared war on the manual production of content. We declared war on service models, meaning that if I need information, I need to ask you, can you provide me with the information? We want everything to be self-service. So all data sources are available for everyone so they can base their opinion and make their decision faster without the need to go through people that have that information removed, all this hiding, and these information pockets. I wouldn’t say we’re there. There’s a lot of still work that needs to be done but the direction is self-service, right? So people can make their own decisions. They know where to find information. And it’s an ongoing evolution of scaling the organization, making teams independent, removing dependencies and complexity, streamlining, clarifying, and delegating decisions. And technology is a big part of that.

Coming towards the end of the session, I’ve learned a few things and the one I liked most is learn, document, and enforce. I think that’s a great lesson to start scaling your business in a predictable manner. And I’ve also learned not only from you but also from personal experience that saying customer-first is one thing b but truly implementing customer success management really helps SaaS companies not only to become successful but also predictable in their growth. So don’t just say you’re doing customer-first, but also document and enforce it with the right tools and technologies. So Guy, thanks very much for the insight into this and, well, hopefully, we’ll meet at a new SaaS university somewhere in the future when conferences come back in this world.

Yeah, absolutely. We’d love to.

Thank you very much.

Thank you very much for having me.