Will your CX be the next global sensation?
It’s Friday night, the work week is over, and you’re looking to unwind. Do you want to be the type of person who orders whiskey? Sure. But at the end of the day nothing will get you in the party mood like a Mai Tai. Here at Caspian Studios, we advise that you drink responsibly…we also advise that you find your closest Mai Tai and let your hair down.
Just like the perfect mixtures of a cocktail, your customer experience is a delicate balance. Our guest today, Jake Reichert, VP of Engineering at Yotascale, has the secret ingredient to making CX perfection: engineers. In this episode, he shares how bringing engineers into your customer experience improves metrics across the board.
--------
"Get engineers on customer calls as much as possible. It leaves a lasting impression and makes engineers care more about their product." - Jake Reichert
--------
Time Stamps
* (0:00) Mai Tais are your secret CX ingredient
* (7:17) What is Yotascale
* (10:11) The engineering behind your CX
* (14:35) Shifting to your customer's perspective
* (18:28) Making engineers your secret ingredient
--------
Sponsor
This podcast is presented by Oracle CX.
Hear more executive perspectives on CX transformation at Oracle.com/cx/perspectives
--------
Links
Narrator: Aaaaah…Oakland, California. The place where this podcast is recorded. A mere 2,402 miles from the shores of Hawaii. White sands, tall palms, gentle breezes: only in your dreams.
Oh what I would give for just a taste of that life.
And it was that feeling that intrigued our hero Victor Bergeron in 1934. You could say that Victor spent his life on island time. He opened a small bar called Hinky Dink’s on San Pablo Avenue and 65th Street. He was mostly serving beans and beer.
But when the Tiki craze swept through the Bay Area, he realized the solution wasn’t to make better beans and beer. It was to give his customers what they wanted - tropical drinks in a full on Tiki bar. And Vic was his own number one customer. If it wasn’t good enough for him, it wasn’t good enough for them. So he became obsessed with refining his custom rum creations. He stressed the quality of the ingredients and was obsessed with all the different kinds of rum.
By 1944, Americans had become obsessed with Polynesian culture. Who could blame them? There was still fighting on both sides of the ocean and the Great Depression was not yet a distant memory. Peace and tranquility meant lounging on the beach in some exotic locale, with a Daiquiri in your hands.
Hinky Dinks soon became… Trader Vic’s, after a nickname that his first wife gave him. because he would often trade drinks and food for good ands services. And Trader Vic had built a reputation for serving up some of the best Tiki drinks this side of the Pacific.
On a very fateful night in 1944, Trader Vic would make history. The wooden shack was packed as always, and after the last customer had finally shuffled out, Vic plopped down at the front of the bar. He liked to end his evenings on this side of things, where the regulars sat. It reminded him what it was like to be a customer in his own establishment, and not just the owner behind the counter.
As he stared now at the wide selection of spirits on the wall, he realized they were due for something new.
“What are you thinking, Trader Vic?” asked a voice from the back of the room.
It was Ham and Carrie Guild. The friendly Tahitian couple must have snuck in through the kitchen door. That’s what Vic got for lending his friends a key to the restaurant. They loved to give feedback during these late-night experimentation sessions.
“I feel like we need something different,” said Vic, rising to go behind the bar. “Something simple, like a Martini or a Manhattan.”
He reached for a bottle of seventeen year-old Jamaican rum called J. Wray Nephew.
“The other ingredients should enhance the flavor, not overpower it.”
He grabbed the orange curacao, orgeat, and a freshly squeezed lime.
“It doesn’t need to be technically perfect,” he added, eyeballing the measurements. “It just needs to embody the tropical spirit and give the customer something they’re not already getting.”
He added a dash of rock syrup and some shaved ice to a cocktail shaker.
“So,” he said, divvying it up among three glasses. “What do we think?”
Ham and Carrie both inspected the amber liquid, and then Carrie took a sip. Her eyes lit up.
“Maita’i roa a’e!” she gleamed.
Translation: out of this world; the best. Thus was born…the Mai Tai.
So put on your flower leis and get out your swizzle sticks, because today we’re heading to a tropical-themed paradise to remind you that sometimes, you’ve got to drink your own cocktail.
Intro: Welcome to Often Imitated, a podcast about remarkable experiences from the past, and how they inspire people to create great customer experiences today.
This episode is all about the importance of being your own consumer. For CX leaders, it can be difficult to figure out where your products are successful or unsuccessful if you’re not trying them out yourself. In this episode, we’ll hear from Jake Reichert, VP of Engineering at Yotascale. But first, a word from our sponsors.
Often Imitated is brought to you by the generous support of our friends at Oracle. Make every interaction matter with Oracle Advertising and CX. Connect all your data and empower your entire business to deliver exceptional customer experiences from acquisition…to retention…and everything in between. Hear more executive perspectives on CX transformation at oracle.com/cx.
Narrator: The Mai Tai became a hit, first spreading to Seattle in 1948, and then finally to Hawaii in 1953. Elvis popularized it in his 1961 film, Blue Hawaii, and President Richard Nixon even counted himself a fan. The drink became so popular, in fact, that it apparently drained the world of its rum supply in the 1940s and 50s.
For his part, Trader Vic would go on to cement his legacy with his chain of “Trader Vic's” tiki bar restaurants. Twenty-one locations rose up from New York to London to Singapore, hawking island libations like the Fog Cutter, Scorpion bowl, Queen’s Park Swizzle, and Doctor Funk of Tahiti. But the Mai Tai remained his crowning achievement, and he was fiercely protective of it. When folks suggested that his rival, Donn Beach, was the drink’s originator, Trader Vic replied, “anyone who says I didn’t invent Mai Tai is a dirty stinker.” This wasn’t just business to him; it was personal.
And the Trader Vic’s Mai Tai is incomparable. Vic called it Paradise in a Glass and I can personally attest.
And because we love a good Imitation on this show, there are many who claim that Trader Joe’s was took some creative inspiration from ol’ Trader Vic.
Not everyone makes a product as easy to consume as a Mai Tai. Software, for instance, has less alcohol content. But Yotascale VP of Engineering Jake Reichert knows that if you’re going to solve a real problem for your customers, you’ve got to be using it alongside them.
Jake: I think it's critically important to go through that dogfooding process of using your own product.
Narrator: We opted for the mixed cocktail analogy instead of dogfood. Jake’s dog Teddy would disapprove, but I am sure that Jake would approve, as he has personally made the narrator of this podcast many an tiki drink.
First, here’s some background on Yotascale.
Jake: So you Yotascale is software that's used for cloud cost, visibility And recommendations. Um, anybody who's been a CIO or VP of engineering, probably well aware that this is one of those painful line items on. Budget and one of the most, um, inscrutable, usually it's second for most people after only head count.
What our software does is aims to take some of the pain out of that process to understand better, uh, where you're spending that money, how you can think about how it's being allocated either across different parts of your companies or different projects, and finally to use big data machine learning algorithms that we've built to give you actionable recommendations for how to reduce some of that spend in places where it's not really ness.
We're a growing company, and I think that it's just an area that I think there's so much, um, There's so much pain that people are experiencing from it. That I think that it's a really the it's, it's something that's very timely right now to, to be involved in.
Narrator: This isn’t just lip service. As a seasoned engineer, Jake knows this problem firsthand, and he is fully invested in offering a solution with Yotascale.
Jake: As long as I have been an engineering executive cloud compute expenditure has been one of the largest expenditures for the company. Uh, the difference with cloud computing is that because you are moving a lot of your infrastructure from machines that you've purchased to, uh, be, or do utility model. It's very easy to overbuy, right?
So, uh, even if there's controls put in place, um, so that you don't massively overspend, most companies don't avail themselves to those tools because you really do want to make sure.
Things like auto-scaling to scale capacity, you should need it, but you really do need some really good quality, some really high quality tools to help you introspect on what exactly is going on with those resources And where you can pull some strings to get more effective use out of them. Without us paying an arm and a leg for.
So. It, it feels very gratifying to be involved in working on a product that I think is solving a need that I know people like me have faced, um, for a long time. It's certainly not an invented need or invented problem and trying to convince people of why they might need something like this.
Um, I think. Anybody who is in a senior technology leadership position is painfully aware of how much of a problem this is and how inadequate the current batch of tools out there are and why these sort of next gen tools like Yoda, scaler really addressing some of these needs in ways that tools that didn't exist before.
Narrator: When we asked Jake to give an example of where Yotascale’s high-quality introspection tools can be utilized, he focuses on containerization. Overbuying, containerization: it’s enough to make you want to set up your remote workspace at the bar at Trader Vics.
Jake: So I'll give you a good example is one of the areas that. That requires a lot of instrumentation from us is a containerization, right? Because now you don't just have like a cluster of machines that are used for one particular project.
So if you have your Acme project in the old days, you would have a set of servers or behind a load balancer. And it was pretty easy to see if utilization of that cluster. I went through the roof. You could look and say, well, what's going on? Do we really have a lot of people using this? If so, can we shut them off?
If not, maybe our auto scaling groups were set up in properly and we have a lot of capacity of spun up that we're not actually using, so we can dial that back down. But you, you kind of knew what you should do. It's a lot harder in a containerized universe because for all of the benefits that containers bring, one of the big challenges they present is that?
You might have a whole fleet of machines And you don't know which ones of those machines are being utilized for any given project at any given time, because that workload is by definition, spread across all of those machines to wherever the capacity is right then. So that's great for trying to optimize your cloud spend.
Right. And trying to sort of, um, Optimize your deployment infrastructure, but it's not so great for knowing which parts of that infrastructure are actually costing you, which dollars?
Narrator: Jake went on to explain that Yotascale’s tools can federate in a single-pane interface the cost allocation of containers. That was almost as hard to say as “Maita’i roa a’e!” But trust me, when your CFO comes knocking on your door - or pings you on Slack - this is going to help you have answers.
Jake: So having a tool that can, um, tell you how your cost. Structure looks across multiple clouds and within Canada containerized workloads and across containerized non-work containerized workloads. I think that's where tools like ours start to become a really compelling.
Narrator: So, who are some of the companies that have begun to use this software?
Jake: Yeah, we've got customers everywhere from very large enterprise customers, down to smaller companies that maybe have a more variable workloads, um, or it's, you're very sensitive to costs that they have from their, uh, their customer base. And they need us to make sure that they don't end up upside down on some of the customer deals that they're putting in place.
Um, because they end up underwater on the infrastructure costs.
One of our customers may have heard of them are called Hulu. Uh, so, so the thing that's interesting about them is that they have to make these decisions about how, how they should, uh, carry out, carry out their cloud, compute build-outs and even nest, even getting into things like product pricing, because, you know, they, they charge a flat fee to customer.
But it's an all you can eat buffet in terms of bandwidth consumption, right? There's no limit to the amount of content that any individual customer can consume in a given month. Um, that can be very spiky, right? A lot of times it's in response to. Situations people didn't express expect, uh, early last year, streaming demand went through the roof because of COVID.
Uh, that's something that we were able to help, uh, Hulu get out in front of and manage because we were able to give them recommendations about how to write right-size their infrastructure in response to that demand a similar but different use case from one of our customers would be zoom. A few. If you look at them, they had a similar issue where, uh, they, they.
They suddenly have had demand, also go through the roof, but really in a, in a, in a very profound way, uh, because of COVID. Um, and that isn't quite the same in that. It's not, it wasn't a spike that was due to. Um, people having the sort of psychological reaction to this global pandemic and suddenly wanting this comfort.
If I want to watch something I'm, I'm at home where I've got to Do something to keep my mind occupied with zoom. I think we've all seen a sea change, right?
And so for zoom, it was not just a matter of saying, well, how do we get through this surge of demand? It was really looking at using our tools to look at how can we make a more permanent and substantive changes to our, our workloads and our processes to account for this new reality.
Narrator: The feedback Jake and his team have gotten from their customers has been invaluable. And like Trader Vic, he understands the importance of looking at things from the customer’s perspective.
Jake: We work pretty closely with our customers to get constant feedback from them. Hey, how do you feel about the product what's working for you? What's not, and a lot of times it's from them coming back to us about what is, or isn't working for them. That drives a lot of our next generation ideas.
Um, and I'll tell you, Yoda scale is also a Yoda scale customer. So a lot of our ideas also come from us trying to solve our own challenges that, that we need to solve. That I'm being asked by our CEO to solve as the VP of engineering.
I think it's really, really hard to truly understand where your products are successful or where they're not successful. If you're not. Using it yourself. And I don't mean using it in the sense of testing it as a developer or as a product manager to say, does it meet the specifications? It's not, that's not really what I mean at all.
I mean, you're using it with sort of these fresh eyes of using it as a real tool to solve a real problem. And then seeing if it meets, if meets your needs or not, um, uh, it's it's if You approach it that way,
It's harder to look at it through this lens of, Hey, I've written this thing on paper. It's supposed to work this way. It works that way. Therefore, it's great. Right? Like that's sort of the internal view, but it's not the external view, you know, externally, nobody cares if. The product 100% meets the specifications for it that you wrote down when you were working it out between your engineering and product teams, they care about, does it solve their real business problems?
And really the only way that you can determine that is by using yourself as a customer.
Narrator: “Deep customer empathy” is how Yotascale states it in their customer values. It’s about being personally and emotionally connected to a product rather than just intellectually.
And similar to our pal Trader Vic, who wanted to be as connected to his customers as possible. If you have ever had the fortune of visiting a Trader Vic’s, you can feel how emotionally connected everything at the restaurant is. Each drink it it’s own tiki mug. The care and craft for every item on the menu. Trader Vic wanted to transport you to a different part of the world. Because he wanted to be there with you.
And Jake is trying to foster incredible customer empathy at Yotascale by bringing together unlikely members of his team.
Jake: One of the interesting things that happens in the dynamics of a software development coming. Is that engineers are weirdly isolated from your customer base in a way that no other part of the organization is customer support has to clearly be on the receiving end of it. If customers are unhappy something, um, sales in a very similar way, sales engineers in a very, in a similar way, uh, marketing, they have to be in contact with customers.
We're looking things like C-SAT scores, right? Um, or net promoter scores, um, engineers don't feel any of that. Everything kind of gets filtered through to them. Through one of those lenses of the, those other teams that I just mentioned. so you end up with engineers kind of having both the highs and the lows of the customer journey being really, really beautiful.
Right? you're not forced to experience that, that feeling when a really frustrated customer is yelling at you on the phone, um, because something's not working the way it is and their systems have been down for an hour. Um, the way that a customer support agent may, uh, Just know very, very well.
Uh, at the same time engineers also don't get those highs of like somebody contacting their sales rep and saying, man, all of these things you talk to me about, this is a hundred percent solved by problems. You made my quarter. Thank you so much. Um, so engineers kind of don't get much of that naturally.
And so as an engineering leader, I think it's really important that. Put your engineers out them and find opportunities to, um, to experience that more.
Narrator: Getting engineers involved in the customer journey sounds like it would be invaluable to the engineers as well as customers. But with engineering being such an isolated part of most companies, getting them involved is quite the challenge. Jake has some advice on how to start.
Jake: One of the tools I like to use is try to get engineers on customer calls as much as possible. Uh, sometimes that could just be shadowing sales calls.
Sometimes it could actually be being involved in support calls or on pre-sales deals. They can actually be there as kind of like a sales engineer role, um, and, and hearing firsthand those things that they don't normally about when people say that things, parts of the Proctor greater. Parts are really troubled and, and, you know, and customers are not happy with them.
And I think that that, that really leaves a lasting impression and kind of makes engineers kind of sit up more and really care more about some of those fastest to their product that they, they don't necessarily see working on it day to day when they're not thinking so much about the customer impact.
Cause they haven't had that, you know, very personal, intimate experience with somebody who's actually using.
Narrator: Fostering cross-functional teams and communication has also worked.
Jake: Another thing that I think. More at a, um, a strategic level that I like to do is I like to partner really closely with a director or VP of sales and tell them, Hey, I want to know at the end of every month or the end of every quarter, whatever cadence makes sense.
Uh, give me, give me a rundown of the deals. Deals closed deals lost so we can see what the common themes are there. Right? You, you want to see what are the places where maybe let's say that there's three deals that you saw that were. Th that the sales staff was not able to close because it wasn't a tool that we currently have.
And it wasn't a tool that they'd ever heard that we were planning on building. But you might look at that as an engineer and say, you know what? Those three things are actually pretty closely related to each other. And it's not that far off from what we've got under the hood. Fred was working on that one prototype a couple of months back and we never quite got it done, but just sitting there 90% finished, we could probably take two weeks and finish it up.
And then we could close all three of those deals. Right. That's something, if you've done, if you're not having those conversations, your sales team is never going to know that's even a possibility. Um, so I think that it generates a lot of, uh, healthy conversation. Start getting your engineering team and your sales team thinking of themselves as, as the co-workers that they actually are as opposed to sort of competing forces within the same company.
Narrator: There’s no doubt that Jake’s CX philosophy has evolved over time. From engineer to business leader, he is now much more attuned to the customer.
Jake: I think my viewpoint originally, it was very much shaped by being an engineer and that engineer's lens for the world. I'm trying to build. Products in line with a specification that was handed to you kind of equal success.
I think that that started to shift. Once I moved into leadership positions, um, And started to be responsible for a broader set of people and care about more internally facing, but like, you know, what were, what was the experience of PMs and engineers, uh, UX designers in the process of building these products, uh, making sure that everybody's working on them felt like they were on the same team, getting it ready, collaborating.
I think that produces higher quality software, but then it it's, it's further shifted. You know, the last several years where I've been in more of the senior leadership and executive positions, where you do start through necessity, feeling more of.
that, uh, direct experience of the customer, right? You're talking to more customers directly.
You're not insulated from them. Uh, if customers are unhappy with your products, you're going to hear it. They're unhappy. If they love your products, you're going to hear that, that, that they love them. And, and hopefully if you're a savvy technology leader, you're. You're going to, you're going to hear about or ask why they love them or what parts they love and not just take that as like a pat on the back, but, you know, really, really use that as intelligence that you can use to double down on the places that people love.
And maybe the things where, you know, you spent a lot of time on that, but they're not getting that traction, you know, maybe don't focus on that as much. Um, so I think, I think part of that is. You can't sort of sit in this position of thinking that any piece of software is your baby, right? Uh, like none of them are your babies, your, your children are your babies.
These are, these are tools that you're building for people. And those tools are either going to be successful or they're not.
Narrator: Well said. So what is his advice to fellow engineers and CX leaders?
Jake: You know, if you're, if you're doing your job as an engineer, you're probably building a lot more tools that are, that are not successes than successes, but you're being smart about saying, take the tools that, that weren't working.
And if that didn't work out, that's, that's fine. You know, we learn, that's how we learn is by, uh, making mistakes and learning from them. But those tools to the side, Don't don't invest yourself in the sunk cost fallacy of saying, well, if we just plow another six months into it, it's going to be braid, really listen to your customers.
And if it's something that they feel like the ideas, right. But the execution is wrong. That's one thing go in and fix the execution and get it to where they want. But if the signals you're really getting from your customers or like, I know the reasons that, that you explained to me why you built that thing, but, um, it's, it's not very good and I'm not interested in using it, uh, even if you made the, the UX better.
Um, it's still not an interesting tool. It's not helping me solve the problems I need to solve. Those are the tools where, you know, you can only Polish it so much and it's just, it's just not worth the time. So really paying attention to your customer. In that regard to have the humility, to also understand where your customers are telling you that it does.
You know, I, I hear you that you put a lot of work into this thing. It's not what we need. Please go build something else. I think you have to be open to hearing that as well.
Narrator: Knowing where the customer is coming from is a lot easier when you’re a customer yourself. You understand their acute pain points because they’re your acute pain points. That empathy allows you to be a better CX leader, and to bring your team along with you.
So this week, break the cardinal bartending rule and cross the bar. See what your customers are experiencing and figure out your own frustrations with the product.
Whether you say that your team should eat your own dogfood, brew your own kombucha, sip your own champagne… from now on let’s agree it should be drink your own Mai Tai. In honor of the legend Trader Vic.
And let’s hope that our customer experience can be… paradise in a glass.
This podcast is brought to you by the generous support of our friends at Oracle. Make every interaction matter with Oracle Advertising and CX. Connect all your data and empower your entire business to deliver exceptional customer experiences from acquisition…to retention…and everything in between. Hear more executive perspectives on CX transformation at oracle.com/cx.
This is your host, Ian Faison, CEO of Caspian Studios. Thank you for listening to another episode of Often Imitated. If you like what you’re hearing, tell one friend. This podcast was narrated by me, Ian Faison, written by Ben Oddo, and produced and edited by Mackey Wilson, Ezra Bakker Trupiano, and Jon Libbey. You can learn more about our team at CaspianStudios.com.