How to drive and elevate enterprise product adoption

Sapan Choksi  0:04   

Welcome, everyone, welcome to the Enabling digital with Systems Plus Podcast Series. Today, we have a fantastic guest with us, Amay Jhaveri. And he actually is going to help us understand and decide how to choose a product. So a brief introduction about Amay, he's actually been on both sides of the spectrum, he started his career on the product side, and terms of product development, and helping customers adopt the products. And today, he is working on the services side. Amay, welcome to the podcast series.

Amay Jhaveri  0:42   

Thanks, Sapan, and excited to be here.

Sapan Choksi  0:45   

Fantastic. So, Amay, why don’t you give a little bit of a background about yourself, and then we'll just jump right into it.

Amay Jhaveri  0:52   

Sure. So before, you know, joining Systems Plus, I used to work with a company called Entytle. And at Entytle I was running product management. But I was there from the very beginning, when we were just six people. So, I was of course involved in a variety of roles. And a big part of what I was doing was not just building the product, but also working very closely with customers to ensure you know, they adopted the product, and we implemented the product for their specifications. And we wanted to make sure of course, you know, every customer absolutely loved the product. And a big part of that journey was not just the features in the product, but our overall implementation and post-implementation services that we offered to make them enjoy the product. Now, after Entytle I then moved on, and with Systems Plus, and I'm actually on the other side of the fence, where I'm helping large enterprises actually select the right product that will meet their needs. And my product management knowledge from my previous company actually helps in that, because I understand how things are kind of working in the background, and post-selection, I try to do everything I can to make sure the company, the enterprise adopts the product as easily as possible. And I try to partner with the vendor and the company and the enterprise to make sure you know that the relationship is as harmonious as possible and implementations go off super quick. And, you know, the product is successful within that company.

Sapan Choksi  2:23   

Well, that's a great segue. Because, historically, it used to be that products used to be developed in-house, you know, people used to sort of have their own, “secret sauce” to build their own product, and they felt that what they built in-house was the best. Today, it's not the case today, you know, SaaS solutions have popped up everywhere, the cloud has enabled a lot of that, of course, and, you know, most of the companies are going for what I would call best of breed or, or even to the, to the extent that, you know, the finance department will choose their own product, the HR department will choose their own product, or the marketing department choose own product. And it's become completely disparate from that perspective. So how do you bring it all together?

Amay Jhaveri  3:07  

Right, so it's, you're absolutely right, the landscape has completely changed, there is a countless number of products out there today, for us to choose from, and the buying function of the product has transitioned from typically, you know, being IT to the business vertical, but IT is definitely still involved. Because fine, fundamentally, what happens is, once the product is selected, and we'll talk more about that, you actually rely on your IT team, or your technology team to make sure the product is implemented and embedded into the ecosystem and interacts correctly with other products. So, if you think about bringing it all together, we've now got this sort of hybrid situation where we've got a bunch of legacy on-premise products that were built, you know, many years ago, and then we've got a large plethora of third party products coming in. And these third-party products are coming in super-fast because they're ready to go and deploy and implement. And so all of a sudden, you know, you realize you're almost implementing a new product every month sometimes too. And managing that can become complex, as you can imagine. Yeah. So it's, you know, it is definitely the role of, you know, seeing the role of technology and it kind of changing from developing products do kind of making sure this ecosystem exists in a sort of harmonious way and allows for the business to operate at the speed that they would like to without sort of skipping a beat.

Sapan Choksi  4:43   

Right? So maybe I'm jumping ahead a little bit here, but one thing that has always haunted me and I've been on, I've been on obviously, the product selection side, is that you know, I might have the best product, it looks amazing, feels amazing, etc. But in the end the product, you know, we actually scrap the product two years down the line just because people sort of didn't warm up to it. So, in a sense, what do I have to do? And maybe I'll start at the beginning, right? To make sure that people are buying into this product, as in people within my organization, etc. So, what are the things one should be thinking about when they're actually selecting the product? Because it can be the best product ever that it's built? But if my people don't use it, it's useless.

Amay Jhaveri  5:28  

Yeah, and you're absolutely right. So if you think about it. Now, the selection criteria for products is actually pretty wide-ranging. Back, you know, many years ago, enterprises were building their own product. So, they could customize configure, and create their own use cases, things could work exactly the way they wanted it. Now, you do need to compromise a bit. But what is happening with the evolution of technology is a lot of the new enterprise SaaS products that are out there today, are heavily customizable, and configurable. And, you know, that's one of the big factors you also have to consider when selecting a product. So of course, that's not just it. First of all, when you are selecting a product, you need to find the right product that sort of fits your needs as a business. So, a product that may work for one business may not work for another one. And you have to understand what your business objectives are, and who the stakeholders are, for those objectives to find the right product. So, number one, definitely understand clearly why you need that product and what use case it is serving. And then ensure you have the right people in place. And you have the buy-in when you are selecting the product. So, whether someone from IT and marketing, make sure they are aligned. Because if they're not aligned, then eventually, you know, that battle just affects the outcome of the product’s success.

Sapan Choksi  6:51   

Right. So how important is that alignment? Historically, as sort of I touched on earlier, IT was heavily involved from the beginning, now IT is coming along for the ride. So how does IT make CIO get that alignment upfront? Or are you saying that the business now has to sort of make sure that the alignment comes into the picture?

Amay Jhaveri  7:18   

Yeah, so we actually have seen many cases where the business makes a decision, it was pretty much ready to make a decision and bring an idea, like say, the very last minute, and IT comes in. And typically I saw this a lot in my past organization with Entytle, business was ready business said, Yes, we need this paddock. IT came in and roadblock, nothing happened. And we would be stalled, right. And what happened is that created a very poor relationship between business and IT from what we could see. Because business wanted to go one way it was blocking them. And then IT unfortunately got this poor rap that or you know, it is just blocking our growth and success for the business. What we would like to see and what I have seen being successful is when the IT leaders, the CIO, or the director, or the VP partners with the business stakeholder and the owner, in the product selection process right from the beginning, because every product that is being implemented, fundamentally will require some flavor of technology. And IT in that implementation process, whether it's through data integrations, configurations, potentially deployments, in, you know, interactions and API calls with, say, the website or other products in the ecosystem, you know, a product doesn't exist in a silo anymore. And so because there's so many moving bits and pieces, you need to make sure that it looks as this product has an opportunity for the business to grow. And they feel involved back from the beginning. versus you know, just another thing that's being added on to the plate, because they've already got, you know, so many things that are happening in the business that they have to keep the business operations running. This just adds to it and then they say, We don't have time. Let's do this later. And that later just comes way too late.

Sapan Choksi  9:03   

Right? That's, that's very true. So, one of the very interesting things that I hear a lot lately is out of the box. Okay. So it's pretty funny, like, oh, yeah, I do law solution is out of the box, plug and play. But I'm not actually seen anything that is really plug and play. There's always some configuration that requires some implementation, etc. So how do you actually navigate when people say it's plug and play? And then how do you actually think about implementation configuration when you're actually selecting a product?

Amay Jhaveri  9:34   

I have not seen an enterprise solution that is plug and play. Even a simple one, at least requires maybe I would say, a couple of weeks to a month of implementation. More, right. And you might be like, you know why? And I'll tell you why. Because if you think about an enterprise today, they have a very specific way of operating, and ideally you want to configure and customize the product in a way that fits into that way of operation. Because if it doesn't, you're not going to have the adoption that you need. So very, very simple. We were, you know, implementing a ticketing system for a retailer. And you would think, you know, this is one of those ticketing systems. There's Zendesk, which you know, is a very popular tool, you can today if you're a small business, you can just go up, sign up for Zendesk, and boom, you're going that that's plug and play. But in an enterprise, you've got 50 users, number one, right, that you have to think about, you can’t just sign up and say, here's your access, you've typically got a legacy tool or a tool that you're migrating from. So you need to make sure that data moves over. That's another one. And then, because you know, when you've got more than sort of five or seven users, typically, you will need to make sure that you have the application customized and set up in a way that's sort of friendly for them. So, it can be as simple as certain, you know, nomenclature that needs to be correct. Whether you know, maybe in your business, you call it a ticket in another business, it's called an issue, right? Something as simple as that. You need to make sure that you can either customize or correct some of those things because you want the product to be familiar for the users. Otherwise, it just hurts your chances of adoption. And then finally, even you need to train users, right? And, and training itself can take sometimes a week, two weeks, while they have to go through the product, get adoption, you do UAT, etc. So, plug and play, it's a nice thing to say. And yes, there are many products, which you can just sign up for and get started. But that's typically true for like a small business when you're talking about enterprises, there's always going to be some flavor of implementation and the implementation. And configuration is, is extremely, extremely important in ensuring the product success.

Sapan Choksi  11:56   

So, when I'm actually thinking about the implementation and configuration, usually, do I take the help of the product company? Or do I do it in-house? So are they usually sort of, you know, other service providers that do it? I mean, how does it work? Normally?

Amay Jhaveri  12:14   

That's a great question. So, my ideal answer is you need a flavor of both in that you need help from the product company for the implementation or the product company, and they have partners, and you need a little bit of in house help. So and the reason I say that is the product company will be very good, of course, they're getting their own products set up. And they will be you know, focused on their own product. But what they will not do is necessarily look at how your product fits into the larger IT ecosystem of the enterprise, how it integrates with some of the other products, and how your users are going to be using it alongside other products. That's why it's important to have someone in-house that can help that process. So ideally, you have the product company, they will have, you know the implementation team, which may consist of say a project manager and two or three engineers, depending on the complexity of the project, a solution architect, and then on your side in-house, you should ideally have a dedicated project manager working on this product, depending on the complexity, someone at the right SMEs. So, you need the right subject matter experts that can understand where this product will you know which applications this will integrate with which downstream products it will affect which data it may need to you know, you may need to send into the product so so that you can get all of that done super quickly. And that's the best combination. When you have both teams working together, you have a project manager on both sides want to help navigate the enterprise internally, and then want to help navigate the product and ensure that, you know, that fits perfectly within the enterprise.

Sapan Choksi  13:50   

That makes a lot of sense. I'm going to go back a little bit on something you touched on earlier adoption. So adoption is it's it's a very simple word. But and it really in the end makes or breaks your actual product selection process, etc, is what I've seen. We've see I've seen big implementations where companies have drained multimillion dollars and then just begun to lack of adoption. They they scrapped the project, they scrapped the product. And then I've seen simple, simple products being I mean, not spending too much money, but it's really bother organizing together. So the adoption is actually key. So So I guess where I'm coming from is that we all understand that. But at what point do you need to start thinking about adoption? And how do you ensure adoption actually happens?

Amay Jhaveri  14:41   

Yeah, so that adoption is a huge subject. And you know, I think we can talk a lot about it. So I'm going to try to be as brief as I can. But basically, you know, adoption is important, you have to think about right from the start. So if you think about when you're when you're starting to implement a product, you need to start thinking about what are the core use cases that you're going to sell awful when the product goes live, and you really got to focus down and narrow that scope, to those core use cases in order to, you know, deliver a successful product. And the reason I'm saying, you know, focus on the use cases, and kind of narrow down the scope is not because I want to sort of limit the capability of the application. But what I want to do is make sure the application can deliver value quickly. So the second you narrow down scope, the faster the application will go live, the faster users will get their hands on the application. And the more you have, the excitement will still be maintained. Otherwise, typically, what we were seeing is you selected a product, and then like eight months go by or nine months, or sometimes even a year, and the product finally goes live, the excitement is pretty much dead by then. So if you can prove that's true, if you can deliver some value within the say, the first three months is something you know, I'm just kind of putting out there. But three months, or sometimes even one month, of course, is amazing. If you can deliver value quickly, and show that people are getting value from the product. It keeps that excitement going, and then you iterate from there. So I'm not saying once the scope is locked down, don't do anything more. I'm saying get the product live, get people using it, get people excited, get that feedback, and then iterate on some of those future use cases. So that's one of the biggest things about adoption that you have to think about. Right, from your right from the implementation standpoint.

Sapan Choksi  16:24   

That's some good advice, actually. Thanks. I guess another important sort of topic I would like to touch on is, as part of the adoption process, right, how do I get sort of my people to really sort of understand the product? You know, I guess, maybe, maybe it's more training, I suppose. But basically, how important is training? And who normally does it in a typical product framework?

Amay Jhaveri  16:55  

Yeah. So really, really important. So if you think about, once a product is fully implemented, there's a series of sort of, you know, things that happen after that in what I would like to call a standard engagement framework. Right? So the first one is onboarding the user. So what I have seen being really successful and entitled, we have deployed the application for almost 100 150 users with a large industrial manufacturer, and what they did really, really well, well, number one, they had a dedicated learning and training team, which was, which was nice, but no, what that what that team did, though, was they customized a lot of the training content and training material to fit the context of the enterprise. So a lot of the use cases were very, very relevant to the people who are training where we were, we weren't training people on a demo instance, and saying, Okay, these are things you could do, we were training people on live data on use cases that they will actually could go and use, you know, in the next minute, and, you know, generate leads and opportunities and actually make money off, and it could, you know, help improve their lives, like, pretty much immediately post training. So the number one thing that we actually did, even before training was we used to kind of no different from how some companies advertise their products, you know, consumer companies, you'll see advertisements for products or launches, before the product launches, we always kind of did that, as a teaser, sort of email memo that went out in sort of two or three batches, we would teach the product teams, the use cases that it could solve for them, etc, and create a little bit of hype. And then finally, when we got to training, you know, people are actually excited to get into training, otherwise, nobody wants to do training, everybody. training as a topic is not not fun. But we actually sort of advertised it right? If you think about it, and try to create some hype and show that okay, this is product is coming, these are the amazing things you can do. And then finally, when we got to training, we had very specific use cases that were very, very relevant to the users. And the most, I would say, the best thing you can do during a training is if you can get users to actually log in and do something in the application that generates is sort of like a quick win, nothing like it. Because the second someone can go into an application, do something within say, a half an hour or one hour, that creates value for them, it helps them do something better, you're at a higher level, much higher chance of winning them over. So training and onboarding is super important. If you know, on the product side, you want to make sure that the product has sort of you know that ease of use etc. But then on the enterprise side, you want to make sure you can create those use cases that do create value for your team quickly especially if you're a manager or you can create some goals within the product that can generate rewards for the users very quickly and move on.

Sapan Choksi  19:44   

So, so you mentioned that you know basically, you know you want some quick wins, etc. But then quick wins is that is that a measure of success? I mean, how do you normally measure success in terms of you know, outcome selector or product Oh, isn't adoption. I mean, I guess it must be, like any number of things, which help you determine success in a product. And probably there's no one magic bullet. But what have you seen, in terms of, you know, from a product is how do you measure success?

Amay Jhaveri  20:14   

Yeah, so successes is a very, very tricky topic with a lot of product companies. Depending on the product, sometimes it's very easy to determine success, sometimes very difficult. So you typically when you are, by the way, when you are going and selecting a product, make sure you get the right level of information to measure success to some degree. So whether if it's if it's a sales tool, you want to make sure you can get the revenue generated from that sales tool. If it's a productivity tool, you want to make sure you can get usage reports from, from various users, how they're using the product, you know, how much time they're spending, etc, make sure you get that information. So based on your sort of product and your objective, you know, it could be your measure of success could be usage, right? How many users are using how many times a day, how often some products may only need to be used once a week, and that's fine. But some products may need to be used every day. So understand what that is for your organization and the product. And factor that accordingly. Roi, of course, like if your product has generated revenue, then that's the easiest or the most, the easiest way to measure success is because you can say that, okay, I've calculated an easy ROI on the investment in the product and how much revenue the company has made some, you know, some marketing products and sales products, you know, typically are revenue-generating, or do promise to have a lift in revenue. So that's, you know, that's another way to do it, some products will help you save costs. So a lot of infrastructure management products, right will say, okay, you know, you can turn off the servers, for example, and, and save, you know, a few $1,000 every month. So that's another one. That's, that's pretty black and white. The other the other measure which most pretty much every product company, by the way, is tracking, which you can definitely ask them to share with you is something called NPS, which is Net Promoter Score. And basically, you know, it's that little bubble that comes up and says, Okay, how, how likely are you to refer to this product to somebody else, and it gives you a scale from one to 10. And ideally, you want everybody all the users of the product to be selecting nines and 10s. But anything below five is basically bad, or it's considered bad. And so you can ask, you can actually ask the product company for that score for your company, and see, you know, what people are saying, because if your users are happy about the product, they really want to recommend it to others. And the NPS score is a good measure of how that's done today.

Sapan Choksi  22:39   

Okay, that's, yeah, that's actually a good advice. One of the big issues that I have seen clients face and even, I would say, my organization has faced is that often we select the product, you know, implementation goes really well, adoption is also sort of gone reasonably well. But then I can't, you know, there's always minor configurations as tweaks because of my business, etc, that keep coming in. And I can't keep going back to the product company to keep making those changes, or tweaks, etc, just because it's just, it's getting very expensive. So, and a lot of lot of these product companies say that it's everything is configurable, do it yourself, etc. But I've noticed, especially in these enterprise products, it's not as easy as it's not as easy as that. So how do you? How does one think about, you know, how to how to configure or customize a product, and I know customers is a big word, but let's say even minor customization, etc, just because I need to have have that slightly different, slightly different flavors, and whatever the product actually has, how do I actually go about doing it? Because I can't keep going back to the product company? Do you know and start paying 100 $150 an hour to make make small changes?

Amay Jhaveri  23:58   

Yeah, absolutely. So it's the one of the biggest problems we've seen today with with some companies is they just charge ridiculous amounts for professional services and any small change any small request that you have, you know, get billed and you have to buy a block of hours and sending out every change requires another so w and nobody wants to keep signing you so W so again, like some of the good valid companies will have a good customer success function where at least you can get some of your basic changes, questions support answered. So that's always helpful. But in the long term, of course, the the ideal world is you want and this is where it also becomes super important, by the way, or technology teams is you want them to become comfortable enough in the product where they are able to make a lot of the changes themselves. And going back to the very beginnings upon in selection. Make sure you select a product that you can have do a lot of self service on and that you're not reliant on the professional services team after product and make change Just and that's something you don't really think about when you're selecting a product, you only realize after the products been implemented, and then you're like, why am I spending, you know, 150 200 $250 an hour? For for simple changes, like a field name, addition, export of a file, etc, some, you know, the good products will have this sort of self serve and allow you to do this by yourself.

Sapan Choksi  25:23   

Yeah, that's, that's frustrating is early on. Absolutely. Right. Right.

Amay Jhaveri

So, you know, it's, it just causes a poor relationship. So ideally, get your team trained in, in the product, the, the good way to sort of check for that is some of these products will either have certifications, or academies or knowledge bases or, or something like that, where your your team members can enroll and get sort of service certified or go through the sort of academy training course, which really goes in depth into the products, products with good partner communities, as well, we should have some of these trainings more formalized. So that's another way to check for that. In terms of how you can sort of make sure that you continue to drive success from the product, there's a couple of things that I always recommend, once the product is live, just like how you prioritize the few use cases, to implement a product, every quarter potentially figure out what are the other big use cases you can solve for with a product that fit in the business objectives, prioritize those, get those done, and move on to the next quarter. And you know, keep that process moving. So don't stop when it comes to innovating on a product a company will also be launching the product company will also be launching a lot of new and interesting features, stay on top of that, be involved getting the trainings, get your super users, you know, to have to take the most from the product, because and then they will send you a newsletter that you most likely will ignore about the latest features, try not to ignore that. Because it is important to understand some of the new features and see how they can help and help your product. So those are just some of the ways in which you can continue to drive success have that product within the organization. And then finally, if your IT team, or technology team is sort of self sufficient on the product, you can just have a sort of agile sprint methodology with them on the product and just keep enhancing it. So you continue to derive value, and you're not signing new, so who are not paying per hour, etc. These are your resources, and you can prioritize how you go about innovating on that product.

Sapan Choksi  27:35

Okay, that's, that's fantastic. So I have one final question for you. And I'm gonna put you a little bit on the spot is Think, think back to when you are on the product side? And now put yourself in the customer shoes? How would you measure ongoing success? And I want you to be brutally honest. How would you? How would you? Sort of, because, honestly, I mean, from a product, vendor perspective, you know, I saw the product, probably have its shelf life, etc. And life goes on. But now we focus on one of you. It doesn't stop there. So how do you measure ongoing success?

Amay Jhaveri  28:16

Yeah, so that's the tricky question. The product companies should care about the success, but you're right, once the product has been sold, and the brother renewals in place, etc, and you've got a multi year deal, you kind of you kind of tend to lose track of the exactly around it. So, so as I think as a, you know, as a as a leader within your organization, one of the best ways to sort of, you know, ensure successes. Within that product, you need to make sure that you are constantly sort of innovating and driving new use cases that need to be implemented and adopted on that product. So what do I mean by that? The product, if you will have chosen a good product, ideally, they are putting out releases the new SAS ones at least once a quarter, some of them once every two weeks, some of them once a month. There's a lot of new things that are coming that can help you organizations, these other companies, the good ones are you know, they've raised lots of money, they have large number of customers for a reason. They have learning from so many other sort of peers in your industry and are launching features that will benefit many of your peers and in theory should benefit you. Maybe not all the features, but quite a few of them. How are those being utilized? Are you actually capitalizing on the new features? Or is the product looking the same as it did a year ago? Or two years ago? Are you guys doing the exact same thing if you are, odds are the value you're getting from a product is slowly decreasing quite significantly. And then of course over and above that some of the other things I spoke about when it came to like NPS and and usage are other factors to consider but one of the one of the things that I you know I think is Testing is like basically figuring out when a product is stale in your organization. And you know, it's stale when it basically looks exactly the same when you're driving the same use cases from it. Or for at least over a year or two years, because the ecosystem is changing so fast, there's so many new things you can do. You need to be getting better with the product and with your entire set of products every you know, every quarter every year, and improving your business.