John Purcell has more than 20 years of experience in the technology world. Currently, he’s VP of Products at CloudHealth, a company that helps organizations manage their increasingly complex cloud infrastructure effectively. Prior to this role, he held the same position at SmartBear Software, makers of application performance monitoring solutions. He’s also worn several hats at companies like LogMeIn and Red Bend Software.
In today’s episode, John and I discuss how companies are moving more and more workloads to the cloud and how John and his team at CloudHealth builds a platform that makes it easy for all users—even non-technical ones—to analyze and manage data in the cloud and control their financial spending. In addition to exploring the overall complexity of using analytics to inform the management of cloud environments, we also covered:
Twitter: @PurcellOutdoors
“I think that’s probably where the biggest point of complexity and the biggest point of challenge is for us: trying to make sure that the platform is flexible enough to be able to inject datasets we’ve never seen before and to be able to analyze and find correlations between unknown datasets that we may not have a high degree of familiarity with—so that we can generate insight that’s actionable, but deliver it in a way that’s [easy for anyone to understand].” — John
“My core philosophy is that you need UX at the table early and at every step along the way as you’re contemplating product delivery, and I mean all the way upstream at the strategic phase, at the identification of what you want to go tackle next including product strategy, pain identification, persona awareness, and who are we building for—all the way through solving the problem, what should the product be capable of, and user validation.” — John
“in the cloud, we’re just at the very early stages of [automation based on analytics] from a pure DevOps point of view. We’re still in the world of show me your math. Show me why this is the recommendation you’re making.” — John
“When making decisions using data, some IT people don’t like the system taking action without them being involved because they don’t trust that any product would be smart enough to make all the right decisions, and they don’t want applications going down.” — Brian
“I think the distinction you made between what I would call user interface design, which is the surface layer, buttons, fonts, colors, all that stuff often gets conflated in the world of analytics as being, quote ‘design.’ And as I think our audience is hearing from John here, is that it [design] goes much beyond that. It can get into something like, ‘how do you design a great experience around API documentation? Where’s the demo code? How do I run the demo?’ All of that can definitely be designed as well.” — Brian
“I hear frequently in my conversations with clients and people in the industry that there are a lot of data scientists who just want to use the latest models, and they want to work on model quality and predictive accurateness, etc. But they’re not thinking about how someone is going to use this model to make a decision, and whether will there be some business value created at the end.” — Brian
Speaker 1: You’re now Experiencing Data with Brian O’Neill. Experiencing Data explores how product managers, analytics leaders, data scientists, and executives are looking at design and user experience as a way to make their custom enterprise data products and analytics applications more useful, usable, and valuable. And now, here’s your host, the founder and principal of Designing for Analytics, Brian O’Neill.
Brian: Whether you’re working in a technical product or you’re working in an internal analytics capacity or data science capacity, my guest today, I think is going to shed some light for you on how design and user experience can help turn data and insights into action and valuable services. John is the VP of product at Cloud Health, and I thought this episode would be interesting for two reasons. One, because when you’re managing cloud infrastructure, there is a lot of data flying around and insights need to be derived from this information, and Cloud Health wouldn’t have a business if they weren’t able to create a useful product out of all this information regarding cloud. And secondly because I know many of the internal analytics leaders and data scientists perhaps listening to this show are probably using on-prem storage compute as well as cloud, and so I thought this was kind of a Double-Header so to speak or a two-for-one to get some insights into how John is making his cloud product useful and as well as the processes he’s using to make his product indispensable. So, here’s my conversation with John Purcell, the VP of Product at Cloud Health.
Brian: Welcome back to Experiencing Data. Today, I’m happy to have John Purcell on the line who is the VP of Product over at CloudHealth. John, are you there?
John: I am, Brian.
Brian: Great. Well, welcome to the show, and I’m really excited to talk to you a little bit about what you guys are doing with data products and cloud stuff. And everyone’s talking about cloud and moving their hardware into the ether.
John: It’s good to be with you.
Brian: Yeah. How are things going over there, and can you tell our audience a little bit about what you’re up to in terms of creating useful products about CloudHealth?
John: Yeah. Well, it’s a fascinating time here at CloudHealth. Just by way of intro, CloudHealth has been around since late 2012, and really 2013 is when we broke into the marketplace. And we were focused on companies that are either launching their own applications and services directly in the public cloud or are going though some sort of a transition or transformation and moving work from private data centers into the public cloud for various reasons.
And so, our primary focus as a product and a platform is to help companies do that well, and make sure that when they are operating and running their applications and services in the cloud that they’re doing it efficiently, effectively, securely, and optimally, so to speak. So, the core platform that CloudHealth has built up over the years supports a number of different use cases around analyzing the data flowing out of that to make sure … and giving insights and to help you make sure that you’re doing it well.
So, that’s where we’ve been and the journey we’re on. And as you might imagine, as you described it in your intro, it doesn’t feel new. It feels like it’s been around for a while. But there are a tremendous amount of companies all over the world just getting to this point now and are still struggling with some of the same core problems that companies, that early adopters were struggling with six, seven years ago.
Brian: Yeah. I actually happen to know … I know an independent consultant whose whole … he’s turned his whole focus of his practice into simply helping companies with reducing their AWS spend. That’s how niche it … I’m sure there’s probably other people like him doing the same with other cloud providers and all that, so it’s definitely kind of a hot space.
I thought it’d be fun to have you on the show partly because, A, you are managing a data and an insights product, which is one of the things I like to talk about on the show, but also because a lot of the listeners on this show are also not people working in tech companies but and non tech companies in internal analytics, data science roles, things like that. And so, they’re using probably a mixture of on-prem and cloud services. And so, they might get something on the side just out of what your business is doing as well. But I obviously would like to chat with you about how do you turn this product into, as I like to call it, an indispensable data product where you can’t live without it? So, what’s the biggest challenge with making CloudHealth valuable to your customers, and how do you guys tackle that?
John: Yeah, that directly or some form of that question or some derivative of that question is really what we spend a lot of our time doing on a day-to-day basis as a product group and as a product design function. I would break it down in two ways. And this is not necessarily a new problem in terms of how to attack this as a product company, but it just happens that the focus area, the paradigm, has shifted as focus has shifted to the cloud. And the problem has, as I think, become more complex.
I think the way we … If I could set the table by capturing it this way. We consider the movement to public cloud and the emergence and growth in public cloud as perhaps the most disruptive tech innovation that’s happened in the IT industry maybe ever. Right? Certainly since the early days of personal computing or just computing, period. But if you think back over the last 10 or 20 years, we see this as one of the most disruptive waves or movements, and it’s disruptive in many different ways. It’s disruptive to old models, for sure, and old operating models, but it’s disruptive purely because of the complexity and the different forms of complexity that it introduces. The concept of sprawl and broad based complexity is really hard to get your head around.
And so, that’s why led to the formation of CloudHealth really because a lot of the traditional toolsets and products that have emerged and grown up and seen success in the last 10 or 20 years just haven’t … they don’t seem that fit for purpose in the cloud space, and that’s really what led to Joe Kinsella originally forming the company. And so, at it’s core, to your point, CloudHealth is a data analytics platform that gathers and ingests data from a variety of sources in and around your cloud infrastructure and your cloud ecosystem. It aggregates stores and classifies that data in a variety of different ways, and then it allows you to do several things with the output of that. Number one, you can simply just display it and report on it and, “Hey, here’s some insights that you’re looking for, and here’s what we’ve found.” Or alternatively, you can have the platform just take action for you on an automated basis or plugged into some sort of a workflow where there is a little bit of human or operator intervention.
So, the concept itself is not new. This concept of data collection, aggregation, analysis and output or action is not that now. What makes it difficult is just the size, variety, and nonuniformity of the datasets that are flowing in from the different parts of the ecosystem. And so, as a question of how do you build a product or a platform that fits in in that world and then caters to a number of different personas that care to find the answer to those questions.
From a persona perspective, we’re trying to build for everybody from the financial analyst that wants to know where the spend is coming from down to the individual or team level all the way to the DevOps operator who is trying to make smart decisions about where to place work so that it adheres to budget expectations and so forth. So, I think that’s where as a product and a design team we spend a lot of time is trying to determine what’s the right way to either display that data in a way that’s insightful and flexible enough to be controlled. And B, how do we plug it in as an issue of workflow and take more of a platform approach to say the data’s here, the data’s aggregated and classified, and you can extract it and do interesting things yourself with it. Right? So, that’s we spend a lot of our time as a product and design team.
Brian: Having worked with actual storage companies in the past, I can relate to some of these challenges here. And I’m curious if some of them continue to exist in the cloud space when you’re not managing the hardware yourself.
Speaker 1: You’re listening to Experiencing Data, the podcast that explores how design and user experience make enterprise data products and analytics applications more useful, usable, and valuable. Your host is Brian O’Neill of Designing for Analytics, designer, UX consultant, and advisor to the business leaders behind custom enterprise data products and analytics applications. For more information, visit designingforanalytics.com. If you’re enjoying the show, help Brian out by rating it on iTunes. And now, back to Brian.
Brian: One thing I really like that you said was that you’ve tied some of the analytics to some level of automation and workflow and action. And so, this is something we talk about a lot on this show is that with analytics and decision support tools, if there’s no action and decisions being made at the end, then you’re back to the metrics toilet thing where you’re just spitting out stuff and it’s not really providing value to anybody if they’re not willing to take action on it. So, connecting that dot between this is insightful information to the logical next step you might want to do is X, Y, or Z, maybe automating that. Maybe it’s a handheld process where we just queued up the task. You just have to hit the go button or make some tweaks, but you don’t need to start from scratch with this information.
So, is it a challenge? Well, A, is that right, and B, is it a challenge to figure out how much to automate and how much to give control, like feature level control and settings control, to the user? Because in the on-prem storage world, that was always a challenge, that flexibility versus automation and quote “simplicity.” Some DevOps, some IT people don’t like the system taking action without them being involved, because they don’t trust that any product would be smart enough to make all the right decisions, and they don’t want apps coming down. So, can you talk about that flexibility versus automation piece? Does that sound like a familiar pain, or is that not so much how it is now for you?
John: No, it resonates to a significant degree, Brian. It really does. And I think the change or the new components of that challenge really flow from the fact that the beauty of the cloud or the public cloud and the contract that we enter into when we choose to consume or place work in the public cloud is that when I need more, you’ll give me more. Right? So, when I need more compute, you’ll give me more compute. If I need more memory or storage, you’ll give that to me and I can have that in a matter of seconds. Right? And that’s always been the promise of the public cloud.
Companies don’t transition to public cloud consumption because it’s more cost effective. Right? It’s just a fallacy, I think, that has formed at times or in certain pockets of the market. It’s not necessarily cheaper to do it in the public cloud. It can offer flexibility and it can offer agility and acceleration. Your ability to respond more readily to competitive and market dynamics is really I think what the public cloud brings. And it also offloads this notion of if I don’t have to manage my own infrastructure, I’m certainly not managing the hardware. But this idea that the management burden goes down just because I’m in the cloud is also not true. Right? So, that complexity remains. So, all of this contributes to an environment that is rapidly changing, and changing faster than than infrastructure really ever changed. Right? If we think about the way compute memory and storage was provisioned 15 years ago, we’re dealing with the old days of the hardware requisition form and the long lead times with IT. And I had to think … When I’m capacity planning, I had to really be sure that I give myself enough headroom. Because once it’s purchased and it’s provisioned, then it’s sort of fixed for a longer period of time, whether that’s months, quarters, or in some cases, even years.
The issue with the cloud is I can get it now, dip my toe in the water, and then tomorrow I can expand, the next day I can expand. And before I know it, I can be using 25 different services. From AWS, for example. I’m consuming them to a large degree and incurring cost in various different ways that I hadn’t been before. And that’s all, by the way, decentralized. Right? That’s distributed across an organization. So, you can see now where the dimensions of movement or the dimensions of change just scale up quite dramatically. And so, back to your original point. Connecting data analysis to insight, that’s what we’re looking for. The problem is the core datasets are changing so quickly, and they’re not uniform, and they’re not fixed. And AWS prides itself on its ability to develop 200, 300 new services a year that are designed to remove the complexity. Don’t go manage your own database. Just leverage an AWS service to go do that. Right? And so, the problem is they all have their … many of them have their own cost structure, cost metrics, cost drivers, et cetera, operational structure. And there are various different tools that go along with that to tell you are you … that monitor those services. So, as a data collection point, as a data aggregation point, those datasets look different.
And so, that’s where if I think one of … as an issue of data analysis and insight, I think that’s probably where the biggest point of complexity and the biggest point of challenge for us is trying to make sure that the platform is flexible enough to be able to inject datasets we’ve never seen before and to be able to analyze and find correlations between unknown datasets that we may not have a high degree of familiarity with so that we can generate insight that’s actionable, but deliver it in a way that I can … if I’m a finance person, I don’t need to know what it all means. I just need to know what it costs, or from a DevOps point of view, I can actually take action. And maybe the last point I’ll make here, and this is to your question about trust. In an environment that isn’t changing that rapidly or that dynamically. I’m, again, thinking back to the days of more fixed IT infrastructure where the surface area wasn’t changing that and the surface diversity wasn’t changing that much. I’m quite willing or I’d be more willingly found to just allow automation to take hold, and I can inspect it, I can trust it. But that trust curve follows the same path. Let me see the recommendations you’re making. Let me go validate that the math looks right and that the action looks right. And then over time, I’m just going to go ahead and let you just take the action for me. And in the cloud, we’re just at the very early stages of that from a pure DevOps point of view. We’re still in the world of show me your math. Show me why this is the recommendation you’re making. Super early adopters, advanced adopters, are starting to really embrace automation more and more. But broad based adoption of that as a concept I personally believe is years away.
Brian: Is it because that trust in me would be built when you can suggest that here’s this prescriptive action we recommend that you take. The risk is understood. The IT person tries it and there’s a successful outcome. THat’s, to me, how you build trust over time. And are you saying that the current state of cloud is such that it’s not that simple yet? It’s not possible to produce that prescriptive of an action, or it creates additional work like, “Yep, we can shut down this service, but you’ll have to figure out what to do after that. And we can automate the shutdown or stop … We can stop the money from flowing out of your bank account, but we have no idea what to do with the data, where it will go. It will just disappear.” Is that the issue where it’s like it’s not enough to help me just shut it down because there’s X, Y, and Z follow up actions that must happen, and so I won’t do it?
John: It’s not that difficult to identify. In fact, it’s pretty trivial to identify what we call zombie instances in your infrastructure. Right? Where you’ve spun up a compute instance and it’s been running with less than five percent CPU, no memory utilization, no network I/O. And it’s just very clear it’s not being used. Or we can find an EBS storage volume that is unattached to an instance, a compute instance, of any kind. And so, it’s just become … it’s just hanging out there not doing anything, but it’s costing you money. Right?
So, it’s fairly trivial to identify those things and actually take action. So, that concept is not that complex. And so, that’s one of the first areas that you see companies and customers willing to accept. I’m going to give the platform the capability to go do that for me. Right? It’s quite another, I think, to sort of … Our platform allows you to make rightsizing assessments and rightsizing recommendations. So, we can go profile the usage or utilization of a service over time, and then come back to you and say, “I think you’ve spun this up on a compute instance that you’re overpaying for. You can rightsize to a smaller instance type and save X percent of your monthly spend, and your workload will be fine.” Right?
What we find quite often is because … I’ll go back to what I said before. Because the person or team responsible for creating that infrastructure can be anywhere in the organization. So A, you got to find exactly where it came from, and that’s not always trivial. B, you have to develop some form of workload awareness. And quite often what we see is, hey, we can make recommendations to change the size or type of your instances all day long, but groups don’t always … Quite often we hear, “Well, we need that headroom because of X, Y, or Z component of the workload. There’s spikiness or there’s a certain type of service or app that we’re running that needs that headroom when we’re provisioning and it’s fine. So, strategically or as a matter of business strategy we need that.” Right?
And so, we need to sort of … Systems like that need to develop a level of workload awareness where we can intuit that or discover that. Before, these organizations will just say, “Oh yeah, I’m just going to let you rightsize infrastructure when you think you’ve found a reason or an opportunity to do so.” Right? So, it’s a combination of awareness of what’s going on on that instance, and also knowing where it’s come from and what business context it’s being used in across larger organizations.
Brian: Yeah. No, I can understand that. So, this actually dovetails nicely into my next question. When we originally connected and talked about doing this podcast, I noticed you said, quote “Good UX can disrupt a market and build a business.” And so, I’m wondering, do you think that the combination of user experience and product design practice as applied to these types of problems with workflows, does that enable you to start providing more value? Does it take you from “No one would ever trust us to do this” to “Wow, it’s so great you guys found these correlations and you can move this workload for me. Even if maybe I don’t take the action today, I know where my zombies are.” Does design help you do that or not necessarily?
John: I have religion around this, so to speak. Right?
Brian: Me too.
John: Yeah. So yes, the short answer is yes. Profoundly yes. If you think about, as I was describing earlier, CloudHealth is both … In terms of what the user or the consumer of the … The user of the platform, from their point of view, CloudHealth is both a data presentation product as well as an analytics and a data ingestion and an export sort of engine. And so, in my opinion, I think it’s a little primitive to assume that UX is only applicable to the part that you can see above the waterline. And it’s the function that determines what colors the bar charts should be.
Brian: Right.
John: Right? And how big the font should be. To me, the trap you fall into is assuming that that’s what superior and advanced UX is. And in my opinion, I’m not saying anything revolutionary here to the UX experts in your audience, but you really have to think about, and we try to think about, the ways in which advanced UX concepts, whether that be user research, workflow research and assessment, the connection between different stages, different functions, different areas of functionality in the product are stitched together to support a workflow or a use case.
And so, that’s why we … our UX team really needs to … the individuals on that team really need to be as knowledgeable in how the product is put together and how it works, how the platform works, as anyone in product management or almost engineering. They can go and influence the way the product is specced, designed, and implemented to a certain degree. So, they’re integral to the entire workflow from a product delivery point of view. But I also think … Again, there’s maybe an obviousness to the notion that by deliberately making the product present well, right, to give it that snazzy front end kind of experience and to make it feel contemporary and modern. And the old concept of don’t make the user think. Just make the next steps obvious. Know where they are in their workflow and make the next step obvious. That’s something we try to do certainly a lot of. But I also think there’s a way to apply UX thinking into the sort of I’ll call it the platform side of this value proposition.
So, if you think about interacting with and driving a platform programmatically via API, for example, or programming against the platform and the datasets, I personally think UX has a role to play there if you look at it as a developer experience and the environment you build up around them to allow them to go do that, to go experiment. Whether it’s things like the way we publish API documentation, the way we let developers try different interactions with a platform programmatically. To me, I think UX is just as applicable there. So, what we’re trying to do … And we’re not experts, of course, but we have what I think is a hugely talented, immensely talented, UX organization at CloudHealth. And we’ve really only scratched the surface in exploring ways to have the richness and advanced UX thinking really infect the way we design and deliver product and platform.
Brian: I think the distinction you made between what I would call user interface design, which is the surface layer, buttons, fonts, colors, all that stuff, very important. This often gets conflated in the world of analytics as being, quote “design.” Designing for analytics equals data visualization and user interface design. And as I think our audience is hearing from John here, it goes much beyond that. And yes, it can get into something like how do you design a great experience around API documentation? Where’s the demo code? How do I run the demo? All of that can definitely be designed.
I actually just read a great article from Cassie, I think is Kozyrkov is how she pronounces her last name, the Chief Decision Scientist for Google. And she talked about how I believe they were working on the TensorFlow user interface. And they brought in user experience design to help with that. And her article was about the combination of data scientists working with UX on a product, a technical product, for data scientists. The point being, you can design better experiences around engineering products that may not necessarily have what we think of as a very colorful GUI or an analytics GUI. It’s not a data product or whatever. There’s definitely an experience that can be imagined with the right stakeholders, the right subject matter people in the room. That’s very much what design is about is connecting real IT people that do this action all the time. And what is the finance person’s interest in this? And what does the project management want to do from a value in being on the front line? A leadership thing making the product indispensable. How do you connect the dots on that to make sure when someone sits down at their terminal and starts doing some task. They’re not there for fun. They’re logging in to do a task. What’s that experience like, and is it seamless, and is it hopefully invisible?
I’m guessing most people don’t want to be spending a lot of time looking at CloudHealth. They want to come in. They want to get their work done. Maybe they walk away with like, “Holy shit. I just saved $200,000 this month. I feel like a champion to my boss.” Those are the kinds of things we can design for. I don’t know. I guess that wasn’t really a question. It was just me reacting to some of the stuff that you were saying. But I’m always curious how leaders like yourself are looking at design as a way to level up from just feature requirements, and we need to present these data points because the finance person might want them. But how does the finance person do their job? Right? And so, maybe you could tell us a little bit. Could you give us a use case in your product where maybe there is the old way of doing it or you had a proof of concept kind of stage, and then you had some design attention given to it, and maybe you learned something from that process? Like, “Wow, we never knew that the finance person was going to do X, Y, and Z” or “The DevOps person had to do this prework before they would be willing to move a workload” or something like that. Do you have any examples you could … use cases you could talk about?
John: Yeah. Again, as you’ve said a couple times, there is so much to unpack here. And it’s something I just have this, I don’t know, some people would call it maniacal point of view around this. And it’s not just from CloudHealth, by the way. I’ve learned it over the years and I’ve observed the kind of value that UX can bring to the table at every stage of a product’s life cycle and every stage of a workflow, and have it avoid just being the, “We need a wire frame that’s going to guide us as to what this should look like when it ships.” Right? It’s such a primitive, old, in my opinion, dramatically outdated point of view when you start to think about the concept of design and then certainly UX design.
And so, let me attack the question this way. My core philosophy around this is that you need UX at the table early and at every step along the way as you’re contemplating product delivery. And when I say early, I mean all the way upstream at we could call it a strategic phase, at the identification of what you want to go tackle next. And the UX purists would tell you, “Yeah, of course you would do that, because UX has got a significant user research, pain research component to it.” And again, but I think that flows through every stage of the workflow. And so, what we try to execute here, or what we’ve been trying to execute here, is what I would call pragmatic user experience design. And what I’ve found is that quite often when you have an early stage technology company that has had a profound level of success. And certainly in the B2B or in the enterprise space, and even more pronounced in the IT space where you’re solving hard problems. And we’ve already talked today about the kind of complexity that the public cloud realm really introduces for the user population.
You tend to sort of … You end up pursuing use cases. We got to adjust this use case for this particular user, and this customer made this really great point that we hadn’t thought about, so let’s go attach that [inaudible 00:29:55] of capability. And you just have this thing that grows and has a massive amount of success as a result. But when you look back on it, when you say, “Okay, we need to get serious about UX,” and you bring the UX team and you form it around and they go, “Good Lord, how can I even start to attack this problem? It’s had five or six years worth of its own life before I can get to it.” And so, you and I talked before, Brian, about I had been looking for a leader, a senior level accomplished UX leader, to come join the team here and really start attacking that problem. And so, I tried to approach it through this idea, as I mentioned, of pragmatic UX. And the idea here is for better or worse we have a set of processes, we have a set of techniques that we’re already using and have been using for a while to do pain discovery, to do requirement generation, spec generation, product implementation, et cetera, et cetera, and all the way out to shipping, to production. And that’s happening at a high rate of velocity, very fast cycle times.
And so, it was important to me to go find the right UX experience leader who could come in, observe how the machine works today, and then retrofit best practices to that machine, and that’s the pragmatic component of it. It’s a difficult pitch or difficult sell to join a company that’s in that mode, and then try to just change, change the workflow, the change the pipeline, change the way design is done fundamentally and academically from an academic point of view. And so, the pragmatic point of view is, look, consider this a two to three-year mission. Right? And by the end of it we’ll look back and say, “Gosh, we transformed the way design interacts with every single stage of the workflow.” But for now, let’s find the places where we can influence those things. And my argument is that there are points all the way along that workflow, all the way along that software life cycle that UX can influence. And so, if I were to distill or summarize all of that, I personally believe that UX needs to be at the table whenever we’re talking about product strategy, pain identification, persona awareness and who are we building for, all the way through to how should the product approach solving this problem, what should the product be capable of in order to solve this problem, all the way out to user validation. And glad to say, we have the right team and we have the right leader, I think, to do that, and I’m thrilled to see that come to life.
Brian: I’m happy that you guys have found that. And I think what you talk about … So, I think a lot of our audience are not necessarily UX experts. Most of them I think are not designers at all. So, for those that aren’t listening to this, it’s no different than … Right now, I hear frequently in my conversations with clients and just people in the industry, there’s a lot of data scientists, for example, who just want to use the latest models, and they want to work on model quality and predictive accurateness and all these kinds of things. But they’re not thinking about how is someone going to use this model to make a decision, and will there be some business value created at the end? It’s no different than … There are definitely designers out there who want to, quote “do the process exactly as it’s supposed to be done,” like textbook, the way it was taught when I got my Masters in human computer interaction or whatever. And the reality is different, right? As you said, you have a machine that’s going and it’s probably not going to stop because someone has a theory about how it might be better. So, typically, my thing is you come in and you look for places to make small wins. And eventually you’re going to be like this designers can become … That skillset is like a glue that just seeps into everything. And the next thing you know it’s all over the place and it’s fully integrated. And it doesn’t necessarily mean starting with this massive new way of doing things. It’s something you can slot in to make change happen in positive ways.
But part of that is finding the right people, and it sounds like you’ve done that, which is great. But it’s interesting to know that you … It seems like you find that that’s relatively … an indispensable part of your process is having user experience considered. In my experience in the industry outside of the tech product world, this is very much still a new thing. There’s often, quote “report developers,” Tableau developers. In places where they’re not necessarily building internal tools, this concept of a UX person coming to connect the dots is fairly new. So, I’m hoping for those of you listening that are in a non technical product space that you’re hearing how in this case this product is for IT people, finance people, people that you probably have in your organization as well. And whether it’s Tableau or it’s CloudHealth loading in a browser, that part doesn’t really matter. It’s really about whether or not you want to connect data to actions that people actually take, and hopefully you see business value result at the end of that. That’s really what the design piece is about, at least from my perspective.
John: It is, Brian. And I think if I were to, just for a moment, I’ll take liberties here and just talk a little bit about the vision that we’re trying to pursue here. We see a future not too far off where absolutely bonafide non technical people, or people who are not necessarily in tech roles, whether they be … Let’s just simplify it and call it the person who’s running a line of business, whether that’s a GM or some sort of business operations role where you can abstract … The path we’re on is one where we will absolutely have to abstract away all of the complexity associated with running and operating infrastructure, and abstract that away from the person who just cares about attracting users, converting users from trail to commercial arrangements, delivering value, delivering use cases, and doing all of that while adhering to some sort of strategic operating plan where profitability or growth or top line, bottom line, et cetera is important.
And so, the world we see as we look out is one where all of the complexity associated with data aggregation, big data analysis, insight generation, automated action taking, reporting, that’s all just abstracted away. And then the line of business leader can say, “Here’s the strategy I’m trying to execute with this application or this service. Just take care of it.” Right? The sort of growth and complexity that we talked about very early in the session today is, to me, that’s perpetual to some degree. That is just going to continue to grow and continuing to gain momentum far beyond any human’s capacity to manage it. And that sits at the core of this platform vision.
The only way, in my opinion, or certainly core to the way we will be able to deliver on that vision to businesses is to make sure that I don’t need a line of business leader to have an advanced degree in computing or an advanced degree in data analysis or know how to … has walked a mile in the shoes of a DevOps professional. We shouldn’t need that to be able to make these kinds of decisions. And UX is such a profound way to make that possible.
Brian: I think that’s a great closing thought here. And we’re getting up on our time. But is there any … Just two last questions for you. Is there a single takeaway you would give to an audience here that’s … Again, we do have a mix of probably some technical tech products product management leaders, but we have our internal analytics practitioners and CDOs, CXO, those types of people, data scientists. Is there any closing advice of there was one thing that they could do to make their services better that you might recommend?
John: One of the things I mentioned earlier is how the world of cloud adoption or placing workloads in multiple clouds where at the end of the day and in the near future you won’t care where it goes so long as it supports the strategy you’re trying to execute. If that’s the backdrop that we’re operating against, then it’s worth noting that there are very, very few companies in the world today, probably less than five percent would be my guess, that are doing this what we might consider right. Right? Or certainly who are advanced in their way of execution and start to look like, or starting to model that kind of behavior. Right?
We have this concept we use in our customer interactions that we call our maturity curve, and it just represents the stages that a company might go through in its adoption of public cloud. And the vision I described sits all the way to the top right, and there are very, very few companies who are there. And so, it’s messy, it’s ugly, it’s awkward. We spend a lot of money. Companies spend a lot of money, sometimes by mistake. And as much as you think you’ve tuned this thing, the landscape is changing so quickly, what you think you’ve got right today will be out of date tomorrow or next week.
And so, as a thought, my guidance would be don’t sweat that. Right? You’ve got to just accept the fact that nobody’s really doing it right or really nailing it. Everybody’s trying to figure this out together and just ask. And we think we’re in a good position to help company figure that out, but equally companies can learn from each other. But the first thing to acknowledge is that we’re not that far behind. Right? You’re not that far behind no matter where you think you are.
Brian: I think that’s good. We have this whole theme of theory versus practical in this episode. So, I think that’s a great closing note, that it’s very much about the journey and the process as much as getting to some theoretical perfection.
John: Exactly.
Brian: Yeah. Well great. Can you tell our listeners where they can find you? Are you LinkedIn, Twitter, any type of place if someone wanted to get in touch with you to learn more?
John: Yeah. So, I’m on LinkedIn, of course. John Purcell. I’m on Twitter at percelloutdoors.
Brian: Okay.
John: Various other places, but those are probably the two primary places you’ll find me.
Brian: Great. Well, I will definitely add those to the show links. Man, John, it’s been great to talk to you here about cloud and in product design and user experience today and making data accessible and insightful, so thanks for coming on the show.
John: It’s great to be here, Brian. And thanks for your time. And enjoy the conversation.
Brian: Great. All right. Well, cheers.
Mark Bailey is a leading UX researcher and designer, and host of the Design for AI podcast — a program which, similar to Experiencing...
Kathy Koontz is the Executive Director of the Analytics Leadership Consortium at the International Institute for Analytics and my guest for today’s episode. The...
In this episode of Experiencing Data, I sat down with James Taylor, the CEO of Decision Management Solutions. This discussion centers around how enterprises...
