All right, Corey, what are we talking about today?
And today Duke, we're talking about moving from abstraction to action.
This is one that's been driving me mad all week. And so in the green room, we managed to put a name to it. moving from abstraction to action. What do we mean by that?
For me, it's, those situations when you sit down with the business and sometimes I define the business as it leadership too, right? Like that level that's abstracted, from the day to day and the technical, actual know how decision making. But knows like the ultimate, destination of the product platform, et cetera.
so it's when you sit down with folks like that and they give you an idea of, okay, so this is what we want to see, or these are the problems that we're hearing, And then fix it, please.
Right. For me, the customers don't necessarily. Know how to ask for what they need.
Yeah.
They have a feeling, a strong feeling, probably even backed up by numbers or evidence or testimony. but they have a feeling that something is just jacked up and they want. A solution, and because they're in leadership positions, they'll probably do their best to articulate what they want. Okay. And I think 1 of the defining characteristics that takes a adequate service. Now, resource to a player in the game is the ability.
To be comfortable in that abstract space, gradually guiding the customer to something specific Ourselves on the back there. Oh, yeah, good.
right? duke, is that, level that takes you to a player in the game, right? Gives you, a seat at the table, chip in the game, however you wanna look at it, right? When you can sit down and these con have these conversations with folks who are only vaguely describing what they want. And really be able to understand that, distill it down into something that's technically actionable.
And then provide that to, folks who can actually, you know, like the tech, a lot of actually is in there, man, but it's provided to folks who can actually do the work. I think that is a skillset that is rare. So many people are just used to popping into, Agile or scrum or whatever the heck the module name is looking, grabbing the stories that are assigned to them. And then just going ahead and building them out.
And then reviewing them against the story requirements, but that worked had to get in there some way. Right.
Yeah. Yeah. And I can't say this enough. The people who are buying. The, the process module and service. Now, the technology and service. Now, they don't know how to deploy it.
Yeah.
what they want, and they know what they want to fix, but they don't know how to deploy. So those, the stories don't come from them and, God bless them. There's tons of partners out there. okay, we've done this 100, 000 times. here's all the things that we've got to fix. Figure out, but for the rest of us, product owners, admins, devs, architects, freelance consultants, we have to go into rooms where they just don't know. Even if they know, it's like, I want asset management.
that's still way too vague. To just start cranking out stories on and so if you're like, if you're a beginner in the space, oh, gosh, this week, Corey, man, so many DMS, can you just send me a ton of exercises to do? Can you tell me what to build? You tell me how to build it? And I'll just use the building blocks and service now to do it. I'm like, you gotta start building the muscle of taking stuff from just raw idea.
To the specifics of what you're gonna build because that's the skill set that gets you the big money
yeah, dude, to me, listening to this as we talk about it, right? It sounds fairly simple to me but I know it's not a simple skill, It's one of the things that I think provides the most value to check writers in the space, right? It's knowing that after they wrote the check that they have someone who can take a conversation with them and turn that into the value that they were writing the check for. Right. And, and I don't think that is a skill set that is practiced often in the ecosystem.
And what I mean by that is, I think it's a skill set that exists, right? I don't think that, a lot of the folks who end up working at partners at a level, right? That, say you and I would, if we were, to go and get a job at a partner right now. I don't think that those folks don't have the skill set. What I do think though, Is that once you get into this mechanized consulting world, right? Like that skillset is abstracted away a bit, And in favor of this is how we do it.
And this is how we've always done it.
yeah.
And so what ends up happening is I think there's this big, a bit of a mix match between listening to your. check writing customer, And implementing what they asked for. and without doing it through your own lens. Right,
Yeah.
because I think that's also key to because it's not bringing your lens to the problem, right? And therefore the solution.
I want to be super clear here. We're not taking partners down. We're elevating them in a way, because, it's great that once you like, once you do a few implementations, you start building a body of expertise. these questions come up all the time. The 1st thing we have to do is answer these questions. And then, they build the guides, They forge the path through the forest and that's. Fantastic. I'm just saying that there's a lot of cases where it's a brand new forest.
Like we don't even know where to go. Um, so I guess we'll start off with example. I can pull from recent experience. I have this customer, they've got a, service catalog that like basically everybody, your organization is like frigging service catalog. Oh, you're going to send me there again. Oh, you know, and nobody likes it. Not that people should, But nobody likes it, both on the requesting end, but also on the fulfiller end. So there's just general malaise around the service catalog.
And so what do the leaders do? They're like, okay, team service catalog sucks. this year, we are going to revitalize a service catalog, go,
All right.
you know, go, let's just line up. Like we got these 400 catalog items. Let's line them up and go. So that's super abstract. Right.
Yeah.
So how do we chop down that tree? Corey?
Yeah, dude. I think a lot of it comes down to bursts, just listening. for me, these are soft skills that we're talking about, from my perspective. being able to listen to your customer and understand what they're actually trying to tell you right now, what they're trying to get to you and because they're going to use terminology that is not going to map one to one with service now, right?
It's not going to map one to one with tech, you're gonna say, okay, we go to the, to the service catalog if they even use service catalog, right? They might say we go to the web page and we do a search and we get 400 things. And what I want to know is how can that be 40? Because there's too much of it. Right. And then what you're, what I'm hearing is, okay. So it's, what we have is too many, too much choice, for people that make good decisions. And how do we maximize, the click to choice ratio.
So when I go into a situation, I know exactly what, I know exactly how to ask for what I want and I get what I want. So that's, you know, it's.
that's definitely something that's definitely something we struggle with. Now, the thing I decided to do at the start was. let's deconstruct it a bit when you say it's bad. What do you mean by bad? People don't like it. so it's getting them to be more specific about their sense of the thing sucks. But at this place, it was, it wasn't there, all we had was this vague political force that the catalog needed to be improved. So. I started just running reports against it,
Okay. All right.
what can we got 400 catalogs items out there, but 400 are people using what items are actually being used, And maybe even how long on average are the things taking. Because basically if you were going to solve a problem, like 400 catalog items, I really only want to focus my efforts on the ones that are being used the most, right?
Oh, well, maybe, maybe,
of the time. Most of the time. Yeah, I know. You could have the one or two that are super politically important and are used 10 times in a year. I get
What? No, no, no. Actually, I was going to go somewhere else with that,
Okay, go.
right? Maybe the items that would be used more aren't being used because they're not being surfaced. ha
Okay. Yes, because that's, what ended up happening. So I ran this report and it was one of the most extreme moments of that is not the way it's supposed to be. So we got, we literally have 400 items, but 50 percent of all catalog traffic was. I'll let you guess. I'll let you guess which catalog item it was.
Oh man. Generic was that,
service request.
oh God, I love that one.
But then, you know, in ServiceNow where it's give me the top X and then the rest goes to other,
Yeah.
other was the second most used. So you got to think about the spread on that. it was this big long, I used a horizontal bar graph and it was this huge long line and then these little itty bitty dots all the way underneath it, because basically 399 were evenly split is basically what I'm getting at.
yeah.
how do we even deconstruct this? So now we've get your arms around. What are people using generic service request for?
So,
9 hospitals in 3 healthcare systems. Merged into one giant mega brand, And it's all you can go to the customers and ask.
I think probably the issue is what are they using it for? Everything
there's going to be stuff in there that they're going to be using more.
Yeah,
Right? So it's great. Great. I got 28, 000 requests. Generic service requests since January. This is where the skill is, right? There's no instructions for this, but you have to have that savvy to experiment, I guess? I'm hearkening back to my grade 7 computer science teacher. Write a piece of Turbo Pascal that will write out a Fibonacci sequence.
Right. Yeah. and how do you get there?
Yeah, but you're sitting there, you're in grade 7, you're like, Whoa,
We can,
how do I even do this? I'm sitting here just so frustrated. And he just kept on saying, you gotta think, you gotta think, you gotta ask questions, you gotta think. And I was at the time, I was like, it's so frustrating. Just show me how to do it.
that's a really good question though. how do you know how to do something that you've never done without somebody showing you how to do it? and without, the person who's asking you to do the thing, being able to really describe it clearly, maybe even clearly in, in your language. There's a thing that I do sometimes on complicated projects where I say we need to define the project vocabulary.
Yeah,
right so that we're all talking about the same things when we say the same words. And, that's very useful, depending on how on the mismatch between, the doers and the askers. if there's a significant mismatch there, then, defining that project vocabulary becomes very useful. Because it tells us how to think about things. And I think in this situation, what we're trying to back into is how do we think about the thing that we're being asked to do when the person who's asking us to do it, right?
That can't necessarily communicate to us in the language in which we're fluent.
I love that, man. I love the, like the project lexicon, the project vocabulary. I'm wrestling with that right now. I've got this, consulting team. There's some language barriers, but how many forms do we have? I'm like, what are you talking about? Forms?
Right.
every table has forms.
Yes. Yeah.
saying forms. They say catalog items all the time. now Monday, I'm going to make a project lexicon. That's a great idea, man. Kudos for that. I guess I owe you five bucks.
Yeah. Yeah. No, you'll I'll put on your tab
Yeah. All right. Thanks.
but it's the truth, and it backs into what you were talking about you've got this data, So our, our service catalog sucks, we'd like you to improve it. And then go right. And now you're trying to figure out, okay, what does suck me? And then so you start digging into the data and you figure out, oh, suck means that the only thing you use is generic service requests. Oh, that does suck, right?
Because that means that, you don't have standard processes that are back ending into things that people are requesting for. Right?
This is where my obsession about reports really helped me out there, Because, one day I'm just looking through ServiceNow reports. What can I use? What's stuff meant to be discover the idea of the Pareto chart. What's that do R and D on what the Pareto principle is. And I was like, Oh, that's interesting. Things tend to not be perfectly even, evenly distributed everywhere in nature. It's just the way the universe works.
Yeah, exactly.
And so if there's 28, 000 generic service requests, they probably center around 2 or 3 types of things.
Most likely.
it just came down to like, going to the view, letting it do like 100 or 200 at a time or whatever. And just going back over the past month. And just reading them and seeing what words popped up a bunch.
And that sucks, man, because
does. It does. But you know what? It also works.
yes,
I've seen the word access five times in this page of 10 records. So let's just, short description star access. Oh, that's 2, 500 of the 28, 000. That's almost 10 percent of all the generic service requests have something to do with access.
right,
which by the way, I said that to the customer and they're like, yeah, that makes a lot of sense. Cause everybody's super angry about, access and how slow it takes to modify the access request and dah, dah, dah, dah. And you know what I mean? And I'm like, wait a minute. What access requests? Oh yeah. We got three or four service catalog items for, to, to like, to aggregate all the cat, all the access requests. So I'm like, okay, but they're being used 500 times.
Generic service request is using 2, 500 times. So they're not using the things that you set aside for this.
right.
so I think I would suggest right now that the stuff that they have is just too complicated, right?
Yeah.
whole one form to rule them all for access requests.
So would it be like too complicated or is it that it's hard to find?
Yeah, probably a good mix of both. Probably a good mix of both. But,
But let's see how this is Q and a, right? Cause that's where the value is. The surfacing, I think that's what we're trying to get at. Yeah. Is, my customers got a problem. Just recapping again. We're like using way too many, service catalog isn't working for them. Then you figure out it's not working because they've got, most of the things that they're using is generic service requests, but then you figure out they use a generic service request, mostly for access requests.
And then you also figure out that they actually have access requests, catalog items, and you're like, what the hell?
Yeah, 20 minutes, 20 minutes have gone by and we've gone from catalog sucks, line up those 400 catalog requests and remodel them to no, no, no, no, no, no, no, that won't work. Because even if we remodeled each of the 400 catalog items, Everybody's still using generic service. We got to peel that onion first. And so now we know we have a firmer thing to dig into that access requesting is a massive problem here.
Right.
then You're a few questions away there. What are people using access requests for? All these people that come in and out, temporary workers, contractors, oh, and so now it's not just a generic access problem. It's an onboarding problem too.
Right.
oh, that means we've got to bring in the HR team. They have their own developer. Oh, now we have, now we got that politics as an item on the checklist.
yep. And maybe, if you keep digging at this thing, then maybe you find under those politics that things go to HR and die. then maybe the access request only works for HR and it doesn't work for the rest of the business. And that's why they use generic. I don't know if that's the case here, but that's certainly an area that I'd start to explore. whenever we get in these situations like this, I start thinking about not just the technical, but the people, right? Is there a people process that's.
Bad here somewhere that's causing folks to do things in a way that I think is suboptimal, but it's more optimal for them than going through, this convoluted people process that is bogging down breaking and maybe not even giving them results at all.
Yeah,
the path that we're taking, right? look at, this is like a series of forks in a row, right? It's a series of forks in a row. And then, each time you approach a fork is almost like a, like dungeons and dragons or, something like that, you approach a fork in the road, both paths are shrouded in mystery. Which one do you take? Right. so you use the collective experience such that you've gathered to get to that fork to choose the best likely path. and you keep going from there.
Man, I would much prefer a divination spell, but I didn't roll a wizard, unfortunately.
Hey man, look, if we can conjure the spirits, I'm all for it.
hey, listen, we're still talking in abstractions, but if I can think of a metaphor, it's just how do you untie a knot?
Yeah.
there's no precise instructions. You just got to look at the thing for a long time and start probing, experimenting. What happens if I pull this part. Okay. I see that moves on the other side. So now that's one extra thing that I know, keep probing. And then as you probe, you have insights that stack on insights. That make your probes more effective,
Yeah.
if you just tease it and not long enough, you get to understand how the whole thing is working. And then it gets looser and looser and looser. And the next probe is more effective. I harken back to my grade 7 compute comp sci teacher again. You definitely got to ask questions.
I think it's intellectual curiosity, right? Likes to be curious.
Yeah.
Yeah.
Please, please. As you're entering the service now, ecosystem newcomers, please. Now today, pray these words with me right now. Like I am not an order taker,
Yeah.
There's outcomes that you have to fulfill, but break the order taking mentality. Hey, they just asked me to do this. That's what I'm going to go do. Oh, no. Dig deeper. Ask questions. And you do that on the small scale with the small stuff they're sending you now. And then it just gets easier and easier You train yourself up and then someday you'll be in the scenario I'm in right now, where it's like the customer's looking at you and make these bad feelings go away,
Yes.
and taking it from that to, you plan execution results that matter, I'll give you another example. They have these two asset managers. It's a big merger and acquisition operation, right? So there's basically three or four companies that are now recently become one company. Two of the companies have people that got these giant Excel sheets and we call them asset managers. And so they come up with Hey, get SCCM data into service now, because we need to do asset management on computers that we own.
We give it to the outsource, partner team and they're like, oh, SCCM integration, boom, specific move. And then it's 3 weeks later, the project's complete. Everything's in we clearly tested the integration, but nobody's happy. You know what I mean? Nobody's happy. leadership's trying to deconstruct but we close the project and we close it on time. Like, how come not happy? but look closer. We want the SCCM stuff so that we can do asset management on computers. And nobody thought to say, hold on.
Whoa, whoa, whoa, whoa, because asset management is like, how many processes, Corey, like eight,
yeah,
10, like,
a, yeah, it's a, lot in there to unpack.
I got on there and I was like, when you say asset management, what do you mean?
Ha.
Is it just the fact that we have a record in here? It says computer 4, 000, right? Right. Or is it, how does it go from requested to sitting on our dock or all the asset management stuff, but nobody thought to ask that they just saw SCCM grabbed on to the specific and ran with it. Okay.
talking, but. Think of all your work experience as practice for what you would like to be doing with your work experience, right? Because you don't, there's no switch, as you're progressing through your career, where you go from, low level to high level, you go, you get to high level by practicing high level traits, and that means, at the very beginning coming into the ecosystem, like you said, say a prayer with me, I will not take orders.
I'm not an order taker, push back, ask questions, probe, be curious. And in it, because if you do that in that situation, say when you start, if you end up working for, this company and they're like, yeah, no asset management, we got the data in SCCM and you don't just like here, like SCCM, you shut the conversation down and run off and do it, you say, okay, so when we get the data from SCCM and the service, now, how do you want to use it?
what process is this aligning with what's the outcomes for the business,
Oh, the outcomes episode. Yeah, let's just take that whole outcomes episode. Just insert it right here. We'll pause. We'll wait for you and then come back. What's
and all of those things. And so you understand that the, all these things are means to an end, Like service now is a means to an end, right? Like
the end? What's the end? Yeah, exactly.
I just think that's always my North star is service now as a means to an end. What's the end. What are you trying to do? Nobody buys service. Now, just to say that they bought service. Now they buy service now because service now it's a force multiplier. And they hire me because I'm a force multiplier of service downs, forced multiplication right now. We're talking exponentials.
And not just because I know how to use flow designer or write a business rule and know, know a bunch of the API for JavaScript. It's because let's go full on Jedi Master Neil deGrasse Tyson here. The hole like you're made of star stuff, you know, The universe has put you there right there for a reason. And the difference between them being, Oh my God, that was awesome. Look how much better our lives are because of service.
Now, the difference between that and how come people not happy project completed soon, the difference between those two things could be the clarifying lens that you add, not just your flow designer chops, the clarifying lens.
Yes. and that's not to, devalue the flow designer shops you got. Cause once you clarify the lands, right. Then you shine that puppy up, right? Somebody got to build it.
Yeah, you could be the most exquisite flow designer in the world building the wrong thing.
Yeah Right. What is this? This is a diamond pinky ring. I don't have a pinky, you know? So We're talking about action to abstraction, right? All of this, right? Or sorry, abstraction to action, all of this is action now, even though it might seem like it's just another layer of abstraction. Sometimes abstraction is multi layered, multi faceted, right?
It makes it abstract.
right. It's not clear. And the actions that you take to get from that top layer, all the way down to the core, is the value that you're adding to the project. That's important. That's value that not everybody can see. from the perspective of the tech side, right? It's not it's value that not everyone knows how to to get to to execute. And, to distill that, right? I say, be curious, ask a lot of questions poke around, listen, listen, listen, listen, listen, listen to your customer, right?
Cause they're telling you what's hurting, right? You go to the doctor, right? I mean, all right. So look, we're all experts on our own body, but we're not experts on medicine. You go to doctor and your legs hurting. You're like, Hey doc, my legs hurt. They're like, well, is it the patella? Yeah. I don't know. So I look, when I do this, this part hurts, right?
metaphor, man. Ah. So,
there are steps, right? There's things that we can all do. And it's really about the process. It's about going through the process and being curious and creating that rapport and listening, And being empathetic to your customer's needs and really just trying to understand like the source of their pain so that you can deliver a solution that addresses it and not a solution that you want to address or that addresses your pain. Cause that also happens to you. Oh, this is SCCM boom. SCCM done.
And I'm sure to hear SCCM all we've built several, SCCM integrations for clients, we've got a run book for that. Yeah, we'll do this. We'll get this on time for you. Three days, Matt, And you come back and you did the thing that nobody asked you for, but you did it on time. Duke and I'm going to zoom out a little bit here too.
I'm on a rant a little bit, but I'm going to zoom out here a little bit because this is what I'm seeing with a lot of my customers right now, it is the implementation and deployment and execution of things that they didn't ask for is giving them value that they're not looking for, and to the detriment of the value that they're actually trying to realize.
And the things that they, the problems and the pain points that they're, that they continue to experience because they'll because they're not being addressed because folks are addressing the things that they want to be the problem and not the things that are. And, I think this whole episode really is about being able to better align with your customer.
So that you could deliver that value to them, that they actually bought service now for the thing, the promise, when you're in a sales call, there's a promise that's being offered and one that's being accepted, right? Like the promise is being offered from service now that we're going to make your life better using this platform.
Yeah.
and then you're accepting that promise and in exchange, giving them money. So now we got an agreement. the agreement is I'm going to fix your pain and they change. You're going to give me money and then you don't. And if you don't fix that pain, the other side is going to feel really, really bad about giving you money.
That's a great angle I hadn't even considered. Have you ever watched a great sales enablement person work, sales engineer. there's even a saying in the space., sooner you demo, the faster you lose.
Yes. Yes.
And what are they doing before the demo? They are trying to extract the pain. Gosh, I remember when I was working at Vivid Charts and we had this brilliant sales coach. And. we'd be on the line with somebody and we get off and we just raked over the coals. You guys only asked 3 questions, and, that coaching was just regimented of how much can we find out about their situation because then you then the solution specifies.
The points to their pain, but it's just a great, like one thing you can do if you're starting out, or if you're the kind of person who like needs to breach that, I'm just an order taker mentality, find the closest SE that you can find and ask them to walk you through it. See if you can get a call recording or something, just watch a brilliant. Sales person or sales engineer or sales enabler, do their thing. Watch your first call.
It will open your mind and everything that you're seeing there can be applied to an engagement. We
So Duke, that means now we've got to get one of those folks on the show.
Lauren McManaman in episode two. She was a brilliant SE.
Yeah, she was. Yeah.
come
Yeah.
back to us, Lauren.
Yeah, that's a good point. we should definitely get her on to talk about that aspect. I think the last time we were here, we talked a little bit about different things, but this is important, man. It's a super important. And I think it's probably God, I've been using the word existential a lot in my life lately. And I don't know that this is necessarily existential, but, to the platform or to anyone's career, but I do think it's elevate. It is an elevating factor.
To your career and to the platform for any customer that you're working with, they've already decided that they've bought service now and they bring you in. How do you ensure that contract goes from three months to a year? Or how do you ensure that when you're done with that three month contract, they call you back in six months to do another one? Right. Like you elevate. this is what this is about. elevating your game, talking to them, understanding their pain points, and then solving them.
remember we're not selling band aids here. Right. we're peddling cures, you know, and so find a cure, help them find a cure. But you gotta know what's hurting first.
That seems like a great place to leave it. We had just about 37 minutes to record. So what do you think?
Yeah, let's leave it there. Alright dude, this has been great!
Yeah. I love it when it goes this way. All right. Thanks for watching folks. We'll see