Subscribe
Share
Share
Embed
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
CJ: All right.
We're recording.
We
Duke: weeks in a row,
CJ: and
Duke: but what are we talking about today?
CJ: do today.
We're talking about how to win
at service now without service.
Now,
Duke: and what do we mean
by without service now?
CJ: What we mean by that is there's so
much stuff that happens off platform.
That determines whether or not
that's going to be successful, right?
And not nearly enough time is paid to it
and not time, effort, attention, right?
Yeah,
Duke: to like my time as a ServiceNow
customer, as the owner of the
product, , and what are the skills
that allowed me to be successful versus.
, some of the other instances
that are not as successful.
And there's a laundry list of
stuff that we can talk about here.
So anyways, that's the episode for today.
CJ: no, no, it's not the end.
Duke: No, no, no.
I mean,
CJ: start it.
Duke: what we decided to talk about.
, CJ: Duke, you're right.
Ultimately I was prepared, , and
creating service now success.
Through a lot of the experience that
I had in my career previous, right?
And I took a lot of that experience
and I applied it to the service
ecosystem, but . I took the experience.
That wasn't so much technical,
which is weird, right?
Because I've always been a
very , technically oriented person.
Right.
Like I love the tech.
I've always loved the
tech since I was like six.
I still refuse to buy a
desktop off the shelf.
I build all of them myself.
I got home automation kicking off,
but , I can't overlook that most of
my ServiceNow success comes from the
things that are not technical and that
only slightly relate to the platform
, Duke: I would agree.
I didn't come up as a developer.
I didn't even come up in infrastructure.
I kind of . Stumbled into it by accident.
I used to joke around people.
I'm like the least it person in
it, but some might argue that
I've had a modicum of success in
my 15 years of, of doing service.
Now consulting, I've had a
couple of successes in there.
, and so it is beyond just , your
technical ability to pick it up.
I guess the first step on the journey,
, is to demonstrate a high amount of agency.
And by agency, I mean,
this problem is my problem.
Also , it's up to me to find the best
thing to do versus it's up to me to
be told what the best thing is to do.
CJ: Ooh, yeah, yeah, yeah, yeah,
Duke: low agency is like, somebody's got
to tell me what to do and I'll do it.
Low agency is, wait until I'm asked to
provide my opinion on the best path.
And if I'm not, then
nobody will ever know.
High agency is go out, find one or two
or three solutions, and then bring it
to the table with your stakeholders.
Shout out to one of my
former bosses, Roz Agee.
I remember
CJ: so
Duke: HP OBSD admin.
And.
CJ: check
Duke: You can't give me that answer.
Go to your desk, think about
it for 30 minutes and give me a
better answer when you come back.
Or, or I'd say is, you know, it could
be done this way, but it's going
to be like three months of work and
she'd just be like, do better, Robert.
Not in a mean way.
Right.
But she just like, she
just knew that I was.
Not putting my best effort into it.
So she would say, , go to
your desk and do better.
And in an hour, come back and
tell me, and inevitably I'd always
think of two or three pathways.
And often, , the second or third
one that I picked was the better
option, but , she taught me agency.
Adopt this problem.
, like you have to go to my bosses
and tell them what's going to go on.
CJ: It's so funny.
So I'm going to go back, , to
magic total service.
That's two for a minute.
And when I took that tool over, I'd
done , like some windows scripting, like
back in the DOS days to make my games run.
That's where I was with like
programming, but I took, , magic over
because the team that ran it wasn't
given at the time that we wanted
them to do as the ops team, right?
Because we own the service desk.
And so it was important to
us that tickets work well.
And we were rolling change management
and we needed that to work well too.
, but I never run like an app like this
before done any programming or whatever.
, my boss's boss really said, Hey,
, You want to take this thing over?
It looks like you got time.
I was like, , sure I'll do that.
Right.
And at the time, I'm a really techie guy.
Right.
And you know how techs
think about tickets, right.
, and they're giving me the ticketing
system to now go in and run.
And so I, it really took.
A different mindset, right?
I had to really change my mindset
and start thinking about this, from
a perspective of, okay, well,
now you own the ticketing system.
, how do you make that good?
Duke: Yeah.
CJ: And so like you said, that's
the first step in agency, right?
I own this platform now.
Now I got to figure
out , how do I make it work?
, and I know the things that I hate
about it , as a sysadmin or as an
engineer or whatever, like, okay,
so let me see if I can polish those
edges, you know, and on and on.
. But I think to your point, Duke, I was
given the thing and told to make it work.
And because I love a challenge and
I'm never going to fail, right.
I went off and figured
out how to make it work.
And, but I wasn't given
instructions on that.
And I wasn't given directions that
there wasn't even a guide book.
I don't even think we had an
instruction manual, right?
I don't think I had was a Yahoo
group and we paid like for a week
of week of time from a consultant.
And it was all, you know, big out.
And so I did, but what I learned from
that is what we're going to talk about
today, right, is that a lot of the
success came from things that didn't
actually take place in the system.
Duke: And it all starts with agency.
That idea that nobody's
going to come to save you.
Nobody's going to tell
you how to get it done.
It's your baby.
You have to take a personal almost,
?
CJ: Mac, can I tell you about that phrase?
Nobody's coming to save you, right?
Like, yeah, like, I live by it, right?
And so many people who grew
up where I grew up and found
success also live by it, right?
Because it's true, and you experience
it for the truth that it is.
And so, you don't have a choice.
You can wait and what's
gonna nothing happens, right?
When it does come to
nobody's come to save you.
I really have internalized
that and it's all about.
What I need to do next then, right?
If I'm the only person that's here,
then I'm the only person that can do it.
Duke: All right, beyond attitude, let's
give them some solids to take with
CJ: Yeah, no doubt.
Duke: Okay, start now.
Start writing down everything that
you would consider a standard.
CJ: Yes.
Duke: Even if it's simple, like
everybody thinks that we should
have documentation for now.
That can be your standard.
We're going to have documentation,
fill it out as you go, as you get
more, but for all of you youngins
in the space, if you ever get to the
point where you're the owner of the
instance or the customer relies more
on you to give them the advice, like
just start cataloging your opinions.
On things like how many times
have you heard somebody say best
practices, but like, well, where'd
you get that from your head?
Right.
Or, or, or somewhere else in your
anatomy that we won't talk about,
Actually, like how to, how to
set up architectural standards,
but you got to start somewhere
and it's got to be on paper.
Like you can't just pull this stuff
out of your elbow at a moment's notice.
So you got to start writing it down.
And so just imagine again, you're the
highest agency person for this instance.
It success comes down to you.
So you have to decide to what
standard are we going to code,
CJ: Right, how are you going to run it?
Duke: And are we going to
enforce that via instant scan?
How are we using ATF?
How are we using upgrade center?
How are we moving update sets , from
A to B to C, and also , if we have
guests come in to develop for us,
what are the expectations with them?
Lord knows, like how many stories
are there out there where we pulled
in such and such a company to do
something and they deployed some,
updates sell that they built before
and they just deployed it on our site.
And it's all kinds of stuff we don't want.
Like you got to have house rules.
You know what I mean?
, CJ: and you got to know that you got
to have house rules, ? Because you may
not know what the house rules should
be, but if you know that you need
them, you can go and find them out.
Right?
Right.
Right.
Bye.
You know, like our podcast
is a good place to figure out
house rules, but not just us.
Right?
LinkedIn.
It's a great spot to like
the service community on.
LinkedIn is amazing.
The service now community service
now community also amazing.
There's a ton of info.
But unless you don't you need it.
You don't go looking for it.
. So this is us telling you that you need
to know that you need this info before you
get to the point that you need the info.
Duke: There's some really prodigiously
large teams out there, but even
small teams with one platform owner
and three devs, there's still so
much like, well, I do it this way.
You do it that way.
And bad stuff happens with that because
there's just no governance to it.
Right.
Nobody said this is the way
we do things consistently.
Bob still likes to do legacy
workflow, not flow designer.
, and Jane is hip with flow designer.
She's doing flow designer stuff like that.
Somebody should have decided on a standard
for that and integrated it with the team.
It's not enough that you
have the standards too.
You got to communicate it out to
the people that you're leading.
Yeah.
CJ: And then you also got to make
sure that they that are used.
, I got a client, we got a nice, , so
peace right out there around something
but the things that are getting
built, we got to make sure that
they get built according to the S.
O.
P.
S.
that are published.
Otherwise, you just got documents
on the shelf, and I think that part
of it is also very important, right?
It's like you know, that you needed
the, , , architectural governance, right?
The documentation S.
O.
P.
S.
You know that you need these
things, ? Now you have to also ensure.
, they're being put into practice, right?
And you also need to keep communicating
up and down why they're important so that
that buy in continues to be maintained.
The last thing you really want to happen
is for folks to say, well, I don't know
why we spend an extra two hours doing
things this way when I can shortcut
it and save 90 minutes and management
nodding their heads like, yeah, why
are we spending an extra two hours?
Right?
Like, you need to proactively get
in front of them to communicate
what that two hours saves you.
It saves you 200 hours down the road.
Like when your instance is jacked, it
is those things where you have to be
a good steward of the instance too.
And , it's real life flesh avatar.
Duke: man, I tell you what, I got
a brand new metaphor For the whole
idea where the customer says,
don't have time for your stuff.
Like, you have to get this app out for
us, or, or you have to fix this app.
But meanwhile, the house
is burning down around you.
Right?
I've been on jobs where you come
in and we want to deploy SPM.
We want to do this.
We want to do that.
But you get there.
It's just like, no, no, we got
to put out all the fires first.
You can't even begin to think about
something else to deploy right now
because, okay, so here's the metaphor
and aircraft carrier aircraft carrier.
Right.
No
CJ: any Amish on aircraft
Duke: Amish on the aircraft carrier.
CJ: All right.
Duke: Shout out to , my Amish metaphor,
which I do every five episodes at
least, but this metaphor is about
aircraft carriers and aircraft
carriers carry what super whiz bang.
Like awesome jet fighter
technology, right?
We can force project anywhere
we want in the world.
. We can just impose our political
influence wherever we want.
Cause we got the jets.
. And those jets are phenomenal
pieces of technology.
And they do their job extremely
well, but if there's something
wrong with the aircraft carrier,
everybody's day is ruined.
It's not this fighter jet here.
Isn't going to be able to do his job.
All fighter jets on that aircraft
carrier can't do their job.
And our political influence
is gone out the window.
And so if I was ever back in the saddle,
heading up an instance that's the
first thing I would do at a council is.
talk about , the aircraft carrier
metaphor, we have to keep the aircraft
carrier in absolutely peak performance so
that the fighter jets can do their job.
CJ: Absolutely.
And to take that and
extend it into real life.
, if your instance is not working, then
your users can't use it, ? And if your
users aren't using it, then, you got
a whole lot of other problems, right?
, including shadow it and things
that are being captured in Excel
that you never know about and
never get the access, right?
So, , maintain the instance,
make sure that it works well, so
that , your jets, your users, right?
Can utilize it to get their job done.
, Duke: I think linking it to something
physical like that will show your
stakeholders, how there is energy
that must be put into that thing.
CJ: Absolutely.
Duke: carriers need fuel,
which needs to be replenished.
They need repairs.
They need standard maintenance.
A lot of it,
so it's priming them to justify that
there is time and energy that must be
spent making sure this ship goes good.
Shout out to , all my
Navy friends out there.
CJ: Absolutely.
All right.
Duke: well, I mean, but that kind of
leads in that takes us right down the
path into the stakeholder council, right?
Who am I going to convince?
The stakeholders.
CJ: You have to convince
the stakeholders, right?
Or they need to convince you, right?
Like the whole idea of it, ? Is that
we, you've got people who know how the
business works and they get to give you
feedback on how the instance should work
in the best way for the, , the business.
Duke: Like, do you think a
customer does that though?
Like a, like a stakeholder, do
CJ: Do I think that they
represent the business or do
Duke: they tell you
anything about the platform?
, CJ: yes, if you listen closely
enough, do they tell me technical
things about the platform?
No.
Do they tell me important
things about the platform?
Yes.,
my team doesn't use ServiceNow.
Why doesn't your team use ServiceNow?
Well, because we find that it's too slow.
Okay, what's slow about it?
Well, they just, it's just slow.
Right.
And so you get that treatment and
sometimes that's not necessarily
helpful, but if you listen really
closely, you'll say, well, it
just doesn't work for our process.
What's your process?
, we do ABC and then you go into ServiceNow
and you realize , it's built for ABQ.
And you try to figure out, so how
do we build for ABQ when you do ABC?
And then the stakeholder says,
well, nobody ever asked me..
, and so how many people, do you know,
in tech who actually understand the
roles of all the folks business, right?
Not a whole lot, but often they build
things for those roles, for those people
in the business without consulting them.
So sometimes you hear this is slow
and then sometimes you hear this
doesn't work for me , and you don't
necessarily know why and they don't know
why until you really listen carefully
and then you figure out, well, nobody
actually asked them how they work.
And so what we deliver to them is what we
thought they need it and turns out they
don't . They need something different.
And then we insist it.
That we built it correctly, right?
Because now we're defensive.
We spent three months building
this thing out for this team,
and they don't want to use it.
And we're like, well, this
is how you all work, right?
Like this is what, and
nobody ever asked them.
We all just spent time telling them,
well, you need to conform to the tool.
Well, they won't.
Right.
Let's be real.
And look, I don't know.
I feel like this thing is
something that folks need to hear.
They will not conform to your
mal implemented processes.
And that's what I mean.
The things that are off platform.
That help your service
down implementation, right?
They won't, they just won't use it.
Duke: Are you talking
about platform stuff?
Are you talking about Oh, we
deployed XYZ process badly.
CJ: I'm yes, both though Duke, right?
Like , if it's , SPM process, and
we deployed that and the PMO,
it's looking at this thing.
Like, we don't work this way.
And we said, well, this is
the way the system is set up.
You got to use it this way.
And they're like, well,
we don't work this way.
It doesn't work for us.
I want to say, well, we
can't do anything about it.
Do you think that they're still using it?
They're not using it right.
Like they're going to spin up a
company card and go buy whatever third
party shadow it software and their
team is now using that but you've
won the argument and you've told
them, , this is the way that it works.
But you didn't actually
win the users, right?
Because they're not on the platform.
That's what I mean about it.
you've got to make sure that you're
listening to the feedback and that
you are convincing and getting buy
in instead of dictating and telling.
Duke: I would loop that around.
There is a necessity for listening.
And I think that's where a
lot of people find that they.
start naturally like, Oh, we're
going to tell you how, what
we need out of this thing.
And your job is to listen, but you
also need to like circle back and
take leadership of it and guide your
stakeholders to the goals, right?
And we did a whole
episode on this as well.
This will be in the description below.
Leading a stakeholder council.
CJ: Yes.
Right.
Leading.
, Duke: and if there's one thing this
will do for you, which saved my hide so
many times, boil it all down to this.
It shows them that it's not.
You versus them.
When it comes to , when is
this thing going to get done?
, how come this hasn't got a lot
of, it's not you versus them.
It's them versus everybody else in
the business that wants something.
CJ: that's important,
Duke: Yeah.
Yeah.
CJ: Because it allow them to weaponize
their political capital to get priority.
If that is the will of the business,
Duke: We've all been there, right?
The business is saying we need
encryption on this table that
could possibly contain PII, right?
You got the business telling you
that, but then you got somebody else
who's like, the 15th customization
to this report this week.
CJ: right?
Duke: It's not until like your
stakeholders see each other and
realize what's going on, that
they get the idea that like,
okay, there's , a prioritization
that must happen amongst peers.
CJ: Yeah, there's a road map and
look, the road map can change.
. But we all got to agree that
the road map needs to change.
Often.
What happens is, you know,
comes a black box, right?
And everyone thinks that is
dictated in the road map.
And sometimes is dictating the
road map absent business input.
And that's what this Dakota Council does.
It gives you the business input to
the road map, and it gives you the
transparency to so that everybody's
on the same page about the road map.
Right?
So decisions need to be made.
They can be made.
With the full buy in and support
of everyone in the room, instead of
being dictated by it, who typically
has the least amount of political
power in any of these conversations.
Duke: Yeah.
All right.
You got anything else?
CJ: Cross pollination Duke, right?
There's always something somewhere
else that can help you be
successful, creative, or innovative.
In the vertical that you're
in all the service now, right?
Service doesn't exist in a vacuum,
your business doesn't exist
in the back room in a vacuum.
So you should constantly be learning,
not just about the technical aspects
of the platform, not just about how
it does things, but how everybody
else is doing things and then find
those things that can translate.
And bring them in when you start
crossing ideas together, then that's
when you start to get some magic.
Right?
And a lot of the things that I've been
able to give my clients value from
are things that wouldn't necessarily
be out of the box technical.
Like we start talking about processes
and then I start, , going down the
rabbit hole with them on things around
like organizational change management
and organizational, , psychology and
how, , the processes that they've
built aren't necessarily aligning
with how people tend to think.
And what is the culture
of your organization?
Is this a meeting culture?
Is this a culture where
people come into the office?
Is everyone remote?
Did you design your processes in the
system to account for those things?
. So when you start getting into just
the other skills and talents and
knowledge that you have in different
subject areas and bringing them into
the service now discussion, right?
Allows you to accelerate and elevate
what you can do for your clients.
That makes sense.
Duke and my own face on this.
Duke: Yeah.
I think a specific one, which
is going to be the category I
was going to go to next anyway.
Is , learn how to manage work,
manage it, not, not do it.
You got to do the work too.
A lot of cases, but learning how
to manage it is what's really
going to take it to the next level.
And there's teams that are under managed.
And I would say that shows up
in , nobody seems to be working
on the most important thing.
Nobody knows what's going when, and
then there's overmanaged where you're
micromanaged to the point where we
still don't know any of that stuff
because we're too busy answering every
other of the hundred questions today.
Yeah.
CJ: and we need to dive in on that.
, nobody knows what's the most
important thing and nobody
knows what's going when right?
, you and I have had some really
good conversations about that.
Offline about some of the
stuff that you've built around
performance analytics and S.
L.
A.
S.
And how it's just a lot
more, prescriptive, right?
Because you know how to manage work.
And so you're helping them manage to
work through the things that you built.
My point is, is that, yeah, I think
that's a good episode for, for the
Duke: Well, let's get real specific on
a couple of things I would say you have
to understand where your work comes from
and you can't plan a hundred percent.
You can't even plan 75%.
A lot of your stuff is going to come
in as incidents and let's just assume
that most of them are legit incidents.
These are failures.
We didn't anticipate.
It's just work.
We didn't know about that is now present.
And that is always going to follow you.
And it's going to be a
large portion of your work.
So some of your work is going to be
just getting incidents done, but some
of your work is going to be requests.
And you can't just go into like
strictly request delivery mode, like
someone asked therefore do otherwise
you're going to jeopardize what you've
built with your stakeholders, right?
With this roadmap, whatever
you want to call it, this plan.
CJ: Right.
Duke: Whether you use the SPM
module or not, you really got to
think about demand management.
How do we.
Even contend with the stuff that
has been asked for, let alone the
stuff we're going to do, right?
CJ: Well, yeah, right?
Like, and that doesn't that like loop
back around to stakeholder council?
, Duke: it does, but the stakeholder council
is what I think is like the strategic
layer versus this is , the very tactical
layer, we are in the trenches every day.
What do we get done?
Versus , , with the stakeholder council.
, those are gonna be VPs and AVPs and we
don't want to bug them about, Hey, which
of these two requests should we be doing?
No,
this is the tactical
level, like day to day.
What are we doing?
, and , it goes back to the standards.
But you really have to have a
governance about how the work
gets through a demand process.
Simple as it is.
Again, it doesn't have
to be ServiceNow SBM.
It just has to be some mechanism
and an ever improving mechanism
about we have this new stuff.
What do we do with it?
CJ: Absolutely.
Duke: You could take your
Waterfall stuff, your Agilus.
I don't care what work
paradigm that you use.
You just have to have an intake
process, and there's a governance
process that decides yay, nay, how
big and when, and then going back to
your stakeholder council and you're
communicating with your stakeholders
and stuff, you've got to socialize that,?
It's not my fault.
The thing I asked for just happens to be
the smallest thing on the dinner plate.
Right.
But it helps me a lot.
If you say, listen, , we're
robbing Peter to pay Paul this
week and, and, and you're Peter.
CJ: sorry.
Duke: get to be Paul.
, CJ: I 100 percent agree.
I can't see the Trello card, dude.
I don't know if you ever saved that.
Duke: I never did.
CJ: Oh, okay.
Duke: There's something
else you got to do.
Save the Trello cards.
Or at least document your stuff, right?
That's another thing.
Have a mindset of you're
building this for somebody else.
Eventually, right?
Be high agency.
This is my thing.
I'm accountable for it But you're
only accountable for it for a
little bit and then somebody else
will take it over someday and don't
CJ: that's a good point.
Duke: Don't, you know, don't make
them miserable because you weren't
a good steward of the stuff.
Maybe you had good build, but you hit
Lotto, , you GTFO and somebody else is
going to have to come in and learn it.
How long is it going to
take for them to learn it?
If you've been a good steward, which
includes documentation, memorialization,
, maybe it could take them days,
CJ: Yeah,
Duke: a couple of weeks.
I've been to places for months where
surprise, there's this other thing
that inhibits you from delivering
that thing we told you to build.
And that's , months after I got there!
CJ: It's not only just
for future people, though.
I think that's a very, , big part.
It's also a future you, I mean, I can't
describe the number of times that.
I've built something, gone off
to do something else, right.
Got an enhancement request for
the theme that I built come
back and look at this thing.
Like I've never seen it before in my life.
Right.
And the whole documentation
thing, you want to do that.
You want to do it for your client.
You want to do it for the instance, right?
You want to do it for, , the
people who will succeed you at some
point in the future, but you also
want to do it for yourself too.
Right.
So that when you're doing that
task switching, like you can
incur less penalty for it.
And, , nowadays, like documentation
is so much easier than it's ever been.
Right.
Right?
So there's literally
no excuse not to do it.
Duke: Yeah, man, like, cross
train with our AI episodes.
I'm still waiting for a team that
just, run my update sets through
the AI and just have it document.
Not just the objects that it built,
but see what it does about the intent,
, why did we add these priorities
and these categories or whatever,
these business rules, these flows?
I'd love to have an AI that just
interprets that, and then it gives me at
least a starting point of a documentation
that I can, you know, it takes a little
bit of the sting out of the work.
CJ: Absolutely, and I've gotten a
little bit of that, out of chat GPT,
not the intent part of it, not as much,
but definitely , the overarching, this
is where you're doing kind of thing.
And these are the specifics of
what you did doesn't necessarily
get all the way to the intent.
You know, it gives you a good framework
where you're not having to type 3 pages.
Now you only type in
maybe three paragraphs.
So that's always helpful for me.
Um,
The last thing I say is
just, yeah, just 1 more.
Right?
And that's just user feedback.
? Take it seriously you've
deployed the thing.
The thing is out there.
You should be talking
to the people using it.
And understanding how they
use it and understanding the
places where they're not use it.
They don't think that they're
using it well, or they think it
could be better or the places where
they think you did great, right?
Because you can learn from both.
Duke: Yeah.
And really go live.
, isn't the end.
CJ: No, no, it's just the beginning,
Duke: And is there, yeah, is there
exactly, is there, is there really an end,
you know, like everything you build people
use and processes change, circumstances
change, needs change, so you definitely
can't look at an app and say, that's.
Done.
CJ: right?
Duke: you just took one
more step up the stairwell.
And for that matter, , I'll
just squeeze this one in too.
Take a victory lap, you know, if you
deploy something that's good, like, bring
that back to your stakeholder council.
Advertise it within the organization that
like, oh, this team is getting all kinds
of wins because Blah, blah, blah, blah.
Just kind of infects your stakeholders
with confidence that you can deliver.
CJ: I'm glad you mentioned that
Duke because I think that's
incredibly important, right?
Like market the heck , out of the
things that you're doing well, ? , you
got to control the narrative , of
the platform internally, right?
Otherwise, somebody else will control it.
Right?
Like, there's a, this is a vacuum, right?
There's a marketing vacuum here, right?
And if, if you're not the one
that's filling it up, somebody
else will fill it up and they won't
fill it up in a way that you will.
Duke: I've never thought about
it that way, but it's so true.
You know,
CJ: Yeah, right.
Duke: a vacuum, especially in marketing..
CJ: Somebody else will decide to put
perception on the platform and you
want to be the person doing it, right?
Duke: make them contend against you.
If there is contention, right.
CJ: Yeah, but at least the, if you
are being proactive about it, there's
someone who wants to change the
perception of the platform has to counter
your already established perception.
Duke: Mm.
CJ: And that's just harder to do.
Duke: So wherever you're seeing this,
go ahead and hit the reply button
and tell us what you've done, as a
product owner , or a senior consultant
that has made success a lot better.
It has got nothing to do
with the platform itself.
We'd love to hear from you.
Maybe we can get an episode out of it.
CJ: Absolutely.
And, , like , and share and rate
and all of that kind of good
Duke: All of that
CJ: say, smash
Duke: Yeah.
CJ: that like button later.
Duke: All right, folks.
We'll see you on the next one.