WFM Unfiltered

Are Product Managers The Enemy? | Rich O'Farrell

• Rich O'Farrell • Season 1 • Episode 36

Share episode

Message the show!

Is your product manager helping—or holding you hostage?

This week on WFM Unfiltered, Irina brings on Rich O’Farrell, a seasoned contact centre insider turned Product Director, to finally answer the burning question: are product managers the enemy? From call centre agent to the head of WFM product strategy at Verint, Rich has seen it all. And now he’s spilling the internal truths that most vendors hope you never find out.

This episode is a full-throttle breakdown of what really happens behind roadmap promises, AI features nobody asked for, and those “we’re listening” portals that feel more like suggestion graveyards. Rich isn’t here to play corporate nice. He’s here to tell you how product decisions get made, who actually pulls the strings, and why being ignored post-contract is just part of the game.

You’ll hear the blunt truth about why new features don’t work the way you’d expect, why legacy systems behave like confused robots, and why your urgent user feedback might sit in a queue behind some executive’s shiny new AI fantasy. And yes—we talk about forecasting, accuracy myths, headcount confusion, and why engineers sometimes build things they don’t understand (or use).

For anyone who’s ever asked “Why the hell does this tool do that?”—this episode is for you.

Subscribe to WFM Unfiltered on YouTube:
 https://www.youtube.com/@wfmunfiltered?sub_confirmation=1

Show Links:

 

#ProductManagement, #ForecastingFails, #AIBusted, #VendorReality, #CallCenterTech

Thanks for listening.

If you'd like to contact me about the show, you can email me HERE.

If you have questions about working with me on WFM projects and Consulting, you can find The RightWFM website HERE.

Please remember to subscribe and leave a review of you've enjoyed the show!

Irina:

Hi everyone. Happy Tuesday. Thank you for joining us today. We are going to Alabama, a place that I've never been dying to go, and I'm hoping that I'm gonna get a good host if I ever made my way there. But we have an enemy at the gate today. I'm sorry. We have a product manager, a product director, a product owner. Basically the person that makes decisions for our lives be happy or very miserable. So, I'm quite excited to introduce you to Rich. And Rich. I'm gonna hand over to you to ask you to get a little bit more info on your background. But before that, how are you doing? Are you ready for this conversation?

Rich:

Yeah, we're good.

Irina:

Okay, let's see. Okay, let's see. So, shoot.

Rich:

Okay, so, well, I'm not as much of the enemy of the gates as you might think. I actually started working in call centers, so I was an agent on the phones.

Irina:

So you used to be a friend and then you basically betrayed us. That's what you're saying right now.

Rich:

no. I, listen, I had to work with, I've done a lot of work with people on the ground to help them as best I possibly could. So I, worked I worked initially for Phillips and IBM doing tech support, just taking general customer service calls. I worked for Nokia, doing the same thing and doing tech support. And then I did tech support for LG electronics, for all their TVs. And I've experienced what it's like to sit down and have to take calls from people who are not happy and in, in ways that you can't do anything about. I mean, these, all these big companies have policies and a person sitting on the phone is just, I. Most of the time stuck with doing whatever they say you have to do. And I've been through that. So I, there's a lot of that's not not unfamiliar to me. I a but after that, I did move into the product management side, but before I got the product management, I, did I helped in implementation. So I started at Monet software where we were 80 bitty little WFM company. We were the first to go like true SaaS into the cloud. I started there in 2007 and I worked in implementation, so I, and customer success for many years. So I, helped people actually set it up and get it working, went through all their environments, made sure that things would work. And for the most part it did. I mean, Monet was a very, was a, it was like an SMB focused tool. It wasn't an enterprise level tool. So we did things that were. A little bit different than these, the really large vendors would. We, I stayed there until 2019. And I had done product management. I was the senior product person product manager for several years there after a while. we got acquired by Verint in 2019. then I moved into Verint and took over their enterprise WFM tool. And then eventually I was, became director and had a team of product managers doing the WFM under me. I did the business side for Verint. I didn't do the agent side as much, so they kind of separated things into business side and, agent side. And I own the, business side. So the forecasting, scheduling, you know, intraday, realtime management, all of that stuff was what I owned.

Irina:

So all the things that my side of the fence is interested in, right? The.

Rich:

I would, you're interested in all of it, like PTO request and shift swap and shift bidding and all of that stuff, because you have to manage it. just, I, and I did. I, that's not the part that I own. Not, I had done all that previously too.'cause I did it with Monet. But there was kind of a bigger advantage, you know, things are huge compared to little old Monet. So that's,

Irina:

am ready. I'm ready to shoot in your direction because you know what? I'm gonna make you uncomfortable for the sole reason that I'm gonna address to you all the questions that I wanna address to all of the product managers out there. And unfortunately, you're gonna be replied on behalf of most of the things.

Rich:

fine. You got me here. So.

Irina:

Okay. So one thing that user, community, and us down on the ground wanting to know is give me a little bit more information. What does a product manager, product owner do? What is it your job?

Rich:

Okay, so. In speaking in software product owner isn't as much a role. I'll sort of, I'll kind of distinguish these things out. Product owner isn't as much a role, but is a, well maybe it's a role, but it's not like a title. Usually product owner is like a role that, or a task that you do with a dev team. So when you say that I'm gonna own this portion of the product, that product owner is usually the person that is sitting down and writing out Jira stories, you know, and saying, Hey, the product's gotta do this and here's all the acceptance criteria. If they click here, then it does this. If they click here, it does that. that a product owner is a lot more tactical. They're sitting there. Working with the dev teams, they're, going to standups and if you're familiar with Agile, they're, you're gonna do scrum, you're gonna do standups, you're gonna be doing your back and forth, you're gonna be doing your retros. That's what your product owner is doing. Now, your product owner can also be product manager. Product manager is a little more strategic. So a product manager will be doing things generally, like trying to rank the features in terms of priority about what we're gonna do. We'll be doing user feedback and research and all this stuff. And we'll be planning and grooming the roadmap for what needs to be done in the future. I say that, but you need to understand that as much as things are, people will say, oh, you're the owner, you're the product manager. A lot of this stuff is decided way up the chain. We don't get a lot of input and it, and we're just taking it and doing it. We're basically just taking the marching orders and doing them. We do have input on things. I mean, we can push back and we can do it, but a lot of that is decided at a much more, at a higher level by company strategy. So when you look at what's happening now with a lot of these companies, they're like, it's all AI. It's all AI. What'll happen is you'll get somebody at the top that says, look, I don't really care about all these little features that your users are asking for. What we want is a new AI feature that we can get outta market. And then on the hook for figuring out what is the new AI feature that we're gonna do, that we can actually put on the roadmap and put out to get in front of all of these different conferences and place things like Gartner and, you know, all of your, the different that people like to buy themselves to say, we were the most excellent AI company in the world, and all those. those are, that's kind of what happens. You do need to understand that it's not just us going. I like this feature or I like that feature. We should do that. There's a lot that comes from above us and it is a committee decision too. We have to work with go to market and we work with the sales teams and we work with the marketing strategy and all the people that will have a say in what should actually get done. So.

Irina:

I feel the urge to bite like very, hard right now. I'm sorry. You know what? I've been a part of a product team and luckily for me, I was mostly the person. Doing the decision, okay, this is what we need to prioritize, this is what we need to develop first. And do that, Frank, that you're mentioning. Very rarely I was how do I put it? Somebody from higher up told me, no, we have something else as priority. And this was in cases when it came down to contracts being stopped and then we had to prioritize doing something else while we still have something in place. So this was the situation when a user or me, as the person who has that specialty, would have been overruled and would be slapped down and said, oh, you know what? But it'll be very fancy to make a LinkedIn post and buy ourselves an award so we can potentially attract one more customer that we wouldn't give a shit about. So while I perfectly acknowledge and I understand that product teams are in a very shitty situation, what I'm hearing from you is basically we're doing our best, but most of the time we're getting shit from the users and we're getting shit from upstairs as well.

Rich:

Yes. I mean that happens now for sure. We do listen to users and we like understanding, like I can have sat down and tried to do things in the application and gone. This sucks. I would not wanna do this. It's, you know, a gazillion clicks to do something, which should be easy. And there are definitely times where we get to, to move on things like that and prioritize them higher. It's, not always, and you mentioned like custom work because one big customer decides they want a particular feature and nobody else will use that feature, but they're gonna cut you a$2 million cheque. So, you know, from a business sense, it's what, why would we, you know, it's hard to say no, sometimes they're gonna cut you a big check and you, do something, it doesn't really matter how many other people would use it. So certainly I can understand why some of our users might wonder like, why did you release this feature? It doesn't seem like anybody would use that. Well, a lot of times the answer is somebody paid for it.

Irina:

Yeah, no, I, understand that part and it does happen. Custom work do get in the way The, the situations that I wanna discuss with you, and that again, are basically a trouble for all of us users or a lot of us users out there is. Oh my God. I just, I'm getting so frustrated right now even thinking about it when something is being rolled out, when a feature is out there or a new functionality, because the development team decided on their own, it's going to be massively cool because them as people who have zero workforce management background and our developers decided that it'll look cool. So this is the moment when I flip so hard and I literally wanna throw some stuff off the table. It does happen. It does happen.

Rich:

In WFM?.

Irina:

Oh.

Rich:

I, I, I have never, I, and listen, I'll tell you, I haven't ever been through that. Not worthy, not for the dev team. The engineering teams take direction from product across the board 100%. The engineering teams don't ever get to go to, not from my experience, not that may happen somewhere else. I don't know. But certainly from my experience, the engineering teams do not get to make those type of decisions.

Irina:

But it could be that the product managers or that party that's in charge have said, okay, this is where what we're gonna do. It's gonna look very cool. I'm not saying that they themselves have decided, okay, you know, tomorrow we're gonna make that entirely different feature that we think it will look, somebody must have given them the direction, right.

Rich:

Yeah, of course. So. I, it's hard to speak to I that never, I never personally got to go, oh, this will be a cool feature. We'll do this. You know, the, everything has a prioritization process where you look at what the potential revenue looks like. What are your customer like, like you would need to build business cases for certain type of features to be done and say, look, we've got a list of potential customers that have asked for this. We got a list of sales that were lost directly because of this feature. We lost. Didn't have, you got some that might have been a partial loss because of this feature, and you got some that maybe just asked for it, but you can't really say whether it was a loss. So you look at all of that and you try and tally it up to a dollar amount to say, Hey, if we did this feature, there's, you know, a very good chance that we'll get X amount of revenue in a given year. So, I wasn't. Party to being able to have this situation where I could just unilaterally go, oh, this would be super cool, maybe on some really small stuff. But on like roadmap level, like strategy features, those are driven by a lot more than just any product manager. One product manager sitting around, even as a director had to sit down and, had to why we would want to do something or why we would need to do something and we'd try to generally have to prove it out with other people, vice presidents and other directors and things like that. So it's, it, I'm not saying it couldn't happen, but it, I didn't get to just ever make a decision where I was like, Hey, we should just do this thing because,

Irina:

So we're saying that in an environment where the company or the vendor is customer driven, that should not be the case to happen.

Rich:

no, I. I, I would call it market driven where, because most of these things are really targeting, you know, portions of the market. But certainly customer feedback impacts the features that like once you develop a big project, like you have a big project where you're gonna launch a big thing that has a ton of features that's a market strategy type of thing that has to be sorted through. Once you kind of get it out and you're going through MVP and you're going through a controlled release and you're getting feedback from your users about what it looks like and how it works, and if it's good or it sucks then you will get a little bit more say on say, oh, we really need to do this feature. But it's justified. You got a user who said, okay, this is supposed to make my life easier, and yet I had to click twice as many times to get the thing that I wanted. Then you can use that feedback to help drive why you would do some. But those are like smaller level features. not, they're not like roadmap, strategy, or vision. Type of things, right.

Irina:

I hope this recording is seen by a lot of vendors out there, some of whom might really use it to fix their operations. And I'm sending you a lot of hugs and vir, virtual kisses right now. So moving on with this one. Another thing is, you know, that the, the word that probably all of us user hates the most is the roadmap. It, really is a trigger for us because usually we are hearing it in the sense of a promise that rarely materializes into something and. I have personally seen so much time being lost of customers vendors interviewing them and asking them, what do you need? How do you need it? Why do you need it? And then every single customer is basically having the same repetitive story. Oh, I need this for this and this reason. And then it's been put on the roadmap. And then somebody much more clever than the people who are actually doing the job on a daily basis comes and say no. And then we don't even communicate to the customers anymore.

Rich:

Yeah, so I roadmaps change and when you hear roadmap, you need to, it's bad practice. I don't know how to say this very easily, but it's bad practice for. Any software company, w fm or not to, put things on a roadmap and put dates on them and make promises that are far out. I don't know if you've seen these, but you'll look and they'll say, Hey, next three quarters from now we're gonna have X feature. Right? And you're like, cool. Now I've gotta wait three, me. I've gotta wait three quarters only to find out that at some point they deprioritized it

Irina:

Yep.

Rich:

it was a lot bigger and it's gonna take three more quarters. It's really just not good practice to give, you know, we to promise those things at that level. They should, generally any software company should be saying it's a target, but we really can't commit to it. Unfortunately, you know, that the, way that a lot of these customers work is they go, if you don't commit to it, we're leaving.

Irina:

Yep.

Rich:

And so they end up being kind of forced into a corner to say, to commit to it. There's probably times where people know for a fact. Even though they made the commitment, they just can't deliver on it and they make it anyway.

Irina:

Yeah, but it does happen. Let's be honest about it. That's usually the car that vendors are playing and it is very frustrating. And I do understand. I have worked in a product team, I have led a product team. I know that stuff happens. You are dependent on other products, on other projects, on people leaving com, people coming budget being like, there's so many stuff going on. So of course we do have the, patience and the realization that you can have that commitment and things will change. It does change for us on a daily basis, like what our tasks are. But usually when you say, oh yeah, that's a great idea, we are gonna put it in the roadmap, and you never hear for this again. It's for me, it's so disrespectful towards the customer, like it's okay for you to getting the money out of them. It's okay for you to waste their time asking for input, but it's not okay to be decent enough to provide them with the feedback. I mean.

Rich:

Well, for As from a customer point of view, I would just say get it in writing, and if you want it to be done, get a commitment out of them because the, when we say, oh yeah, that's a great idea, we'll throw it in the roadmap, or we'll, us, honestly, I never said, Hey, that's a great idea. We'll throw it in the roadmap. It was more like, Hey, that's a great idea. And we'll put it under consideration because I couldn't necessarily change the roadmap like that, right? So I try to be setting expectations I feel is very important. You wanna set the right expectation to people that, look, I don't necessarily have this level of control. I can't just go, Hey, I'm gonna steer the entire ship all over here. but I can tell you that we would, that, that we'll review it as part of something that we'll review in prioritization. And if a lot of people ask for it, it is true that it gets a lot more visibility. You know, the more people that ask for a feature, the more likely it is, it gets done. You know, it tells the company, you know, that we're, that's something people actually need, because.

Irina:

that's. The ranking is also done somehow on an internal basis, and it's driven based on the marketing position or whoever decided that this feature needs to be released for acquiring another market or whatever, or bigger percentage of customers. But this also can be a feature that will win, renew those new customers because it'll save X amount of hours and it can be something very stupid, something that will take you not much time to develop or configure in the system, but it's gonna be deprioritized because usually, and either to say it existing customers are seeing as less valuable than future prospects.

Rich:

Well, that's just the nature of it. This is the unfortunate reality of corporate business is that as much as they're important, you know, there. Always chasing new revenue. new revenue is always gonna be the more important bit to, to look.

Irina:

How,

Rich:

That's how you get your stock price up. It new, new, there's no way around. And listen, it's not like I, had to sit there through it a whole bunch, but look, you're always looking for new revenue. You just, it's, certainly important to go, Hey, we can't lose existing revenue. But I can tell you that's the way things work. When you're looking at whether or not we're gonna do a feature that we certain that's gonna win us new revenue versus a feature that we've got customers asking for, lemme tell you that they're not taken lightly. When we look at some of those features, we go and when a big customer goes, Hey, I a feature, we'll look and go, okay, well I. You just renewed three months ago. Your next renewal is three years from now. I can put you on ice until six months until your next renewal, and then do the feature now I can chase all this new revenue. I know that's terrible to hear, but it's the reality of the business that's what they're gonna do. We're gonna go, oh, well your renewal's not for, I don't have to worry about this for 24 months. And then I can do that feature in three or four months and get it out to you before you renew so that we can say, look, we did your feature.

Irina:

And then we're wondering why it takes twice as long currently for new prospects to commit to a certain tool and a vendor. Because when they hear the reality of it I would never sign anything in my, I'm gonna use pen and paper. That's how scary it is when you are basically saying. We only will care about you to the moment when we see your signature and we start getting your money after that, we're only gonna start caring about you potentially to the moment when we know that we're gonna absolutely lose you.

Rich:

This is the way it works. I, that's not unique to

Irina:

No, it's not. It isn't. It is. It's,

Rich:

This is, just kind of the unfortunate reality of it. That's kind of how it works. I don't know what to say.

Irina:

yeah. I mean, I'm usually not quiet, but those things are really getting on my ear, so.

Rich:

I had to live from the inside of it for a long time. So it's okay. I mean, this is it certainly, it's frustrating from our point of view too, because we know that there's certain things that we really, should do. We know that our product has gaps in our users tell us. But you know, we're, we don't have the power to say, well, I'm gonna redirect all my development effort to to doing this thing that I know we need to do. Because the reality is we've already got those customers and they will make due until they can't. And then we can deal with it. But in the meantime, we will look at, you know, chasing features and new revenue come in again. this AI thing is probably ubiquitous across the industry where everybody is chasing AI features, and probably a lot of people who don't understand how AI works, expecting AI to be like a magic wand

Irina:

Yes, they do.

Rich:

Where they can have it do things that are not, like even if you can have AI do amazing things, which it can do, you still have to tell it what to do. It doesn't figure it out for you. And I think that there's a lot of people both on the consumer side that are purchasing the software, you know, and the user side, and then some of the leadership side that just sort of expect AI to just magically do things because they don't necessarily understand what it's gonna take to make it do something. If you are doing something with AI that has never been done before, you can't just go research a, you can't go read a white paper on how to do it, right? You gotta figure out, you have to do the research internally and the development and everything to make it do that thing that nobody else has made it do before. That's a big investment. So as much as AI is the big, cool new thing, I think probably what you'll see from a lot of vendors here is kind of the same old regurgitated AI. Stuff. It's like copilot, like Microsoft's like copilot, like agent helper thing where they're like, yeah, I can just, it's, like a large language model that'll up a bunch of stuff that a person could probably look up. It's a lot faster than maybe a human could do it. It could do research and propose solutions and all sorts of stuff and help them with things like that. But how many different versions of that are you gonna see before you see something that's like truly revolutionary that when it first came out is super cool, but now everybody's got it. So what's the next big thing that's gonna happen? And so that next big thing that happens is gonna take one, some, one of these companies, some of these companies to a lot of research and development into doing something that hasn't been done before. And they're very adverse to that. They don't wanna spend a bunch of money'cause there's no guarantee that it'll come out and work.

Irina:

Yeah, my concerns with that is I'm, I keep on saying this, I'm a huge fan of automation. I'm huge fan of AI and I hate the way that we're marketing AI at the moment'cause it's simply not true how we're marketing it. But the beauty of my current and past positions is that I get the opportunity to see a lot, of WFM tools in action. And I can tell you some of them are mostly a replica of one another with slightly different colors that are used. And you just know that the same people who develop the software a have moved out to software B developed it then. And basically even the, consultants that are rolling out that solution are using the exact same language. The features work in the exact same way. We, I sometimes have hard time. If I don't see the colors, I'll be like, oh, this is software A or B or C. And that's my concern with those new AI functionalities that are currently rolled out, that everyone is basically doing the exact same thing, which they assume it is what the customer would need, which is why I'm so frustrated when we are, ignoring current customers, because for me, this is ultimately your audience to tell you what they need. This is who works with your product on a daily basis, and they're telling you, it'll make me very happy if you develop this. So basically, you have a very good chance that the customer, B, c, d prospects or B, CD will talk to them and they'll say, okay, they listen to us. This is what I developed. This is how they're saving us time. But no, We have heard AI and please let me know how. How does that work? Who is the person that will tell the AI, okay, rich, please, we want you to your team to develop this and it should work in this way because for me, this should be a subject matter expert or a specialist in workforce management that can basically give you the framework, this and this, equals this. This is how we want to work.

Rich:

So it depends. I mean, this is the same way with any feature though. It's not necessarily AI, That's the way that you would want any feature to be developed. It's not, AI necessarily. and it, depends. Sometimes you get direction from the very tippy top about what something needs to do and what they expect it to do, and then you just have to develop it. And then there's times where we do serious research with the users to understand what challenge they're experiencing is and then figure out how to solve it. One of the problems that we run into is that users will prescribe their own features so they, they're familiar with how the software works,

Irina:

Yeah.

Rich:

say, here's the feature I want, and go develop it They'll be like, oh, but it didn't do the other thing that I needed it to do, and we'll go, you didn't say that. You just said this. We're like, oh, I thought this would've just, you know, this made, this would just, would've made sense to, to put in there. And it, from a software development point of view, we're basically going, alright, if you're telling us what to do, then we're just doing that. We're not doing every other peripheral thing that might help with it. We're just doing the thing that you're asking us to do. one of the better things that companies need to do is not, and you, might not agree with this, but I, can, back it up, which is you tell us, don't tell me what the feature you want is, don't tell me how it should work. You tell me what business problem you have, what challenge you're facing, what's the actual thing that you need to get done, what's the outcome you're looking for? And let us figure out how to turn that challenge into a set of features or a feature that gets that done for you. The easiest way. That's really the best way to do it. Not, to have a user prescribe what the feature should be because a lot of times the features don't understand how how things work internally. Sometimes software is built a certain way where just doing the thing that seems really easy to do is really hard to do because you have to rip a ton of stuff out and redo it in order to get it to work that way. So it's, better to start with the business challenge you're having and the outcome you're looking for, and work our way backwards to say, this is, you know, where, this is where we're trying to get, let us figure out features and stuff that'll actually get you there.

Irina:

No, I'll give you that. And to be fair to every vendor out there, sometimes it might look very simple for us. Oh, just add another button here and if we click it, it's gonna. Spit out that result. But yeah, that, that's coding, it might change the, entirety of the software. So it's not so easy as for us, end users might look like, so I'll give you that. But the thing is that, let's use something specific. For example forecasts, currently forecast in WFM tools. You know, this is a topic that I'm running quite a lot about.

Rich:

Yep.

Irina:

At the moment, what we have in most softwares is we're loading up or connecting to a telephony system. We're loading up the volumes, the HT and it spits out some workload. And on the back of that workload, we calculate what is the staffing requirements that we need, right? And we might manually adjust those volumes. We might adjust that a HT based on our knowledge. And this is basically the extent to which we have a forecast. And of course we might, at some custom events, we might add some impact here and there. But then the problem that we're facing from our daily basis is, okay, but marketing team comes and says that they would need to load 2000 orders that would reflect in this and that. And there is no way to basically accumulate all of those different business drivers in a good way and to make a very good analysis. And what would be the data produced, why, what algorithms are being used, what calculations are being used. So we're basically seeing an end result that we don't necessarily know how it's being built. We know that we disagree with it because we see the deviations then during the end, but that's it, that's how forecasting currently works. With some exceptions, I'll say that with some exceptions of vendors.

Rich:

A lot of the vendors that I'm aware of the standard forecasting for short term is basically weighted averages,

Irina:

Yes.

Rich:

right? So that you take a five week weighted average and you say, here's what it is, or, you know, whatever you can, and you can usually custom select whatever sets of historical data you wanna do, but it's basically just a weighted average. so for call centers that have, or contact centers that have a relatively stable environment, averaging can be really accurate. I mean, really accurate. Like what? I've done a lot of research into this, and you see some of these folks who are sitting at like a 99 plus percent average, like they're within 1%. of their forecasts all the time. because it's stable for things that are not stable. And Something you mentioned specifically, like with your marketing, where you've got extra, you've got an external, piece of information that's going to influence what's gonna happen in the contact center. There are solutions for that. I to actually watch what I say at this point, and you can keep this in. I just, I, there are solutions that are gonna be out to help with these type of things. They're gonna be become more commonplace, because it's not an impossible solution to do. It's, and the, it's gonna be up to the vendors to really want to solve these type of problems. So the more noise you make about it, the more it's gonna be something that they are going to compete to solve. There are solutions for exactly the type of thing you talked about. Like a, multivariate forecasting tool can take into account what has happened historically, and it can and it can know, you can feed it in data and you can say, historically, we, here's what happens every time. Here's all our history. I have a year and a half of history. I have a year and a half of these different marketing campaigns that have dropped 2000, 1000, 8,000, whatever things that go out. And we know that next week there's gonna be one that drops 4,000. So these new tools, like a, this is where AI can be very useful, that can actually look at all that history and do a, analysis of what's happening and provide a, forecast that would take that into account. That's not unique to anybody in particular. That is just a thing that can be done with a multi-variate forecasting tool. It doesn't necessarily have to be contact centers or whatever the, that's a good example of where, you know, what data is actually gonna be useful to do that with. You may not always know what that data is that may help in that same way. You may not, you just don't know. It's like you got a bunch of, basically you're sitting in a contact center, you're sitting on like a gold mine's worth of data that could potentially help you. you don't actually know which data is actually gonna help. so there are ways to deal with that. I, like I said, I have to, I can't speak too much to what's going on with that, but there, I think you're gonna see that a lot of these things become more commonplace. The thing that I will tell you about trying to figure out how are you going to reverse engineer those results or not. So a lot of these algorithms, a lot of these AI tools, especially some of these neural net forecasting algorithms in beats and neural profit and things like that, you're not gonna be able to reverse engineer how they came up with their numbers. You, either the only way you're gonna be able to gain confidence. This is, a, challenge. The only way you'll be able to gain confidence with these jewels is to see them get it right. So you have to go ahead and trust it up upfront. And then if it gets it wrong, you can say, you're a piece of shit. I don't like you and I'm not gonna use you. But if they get it right then, it earns your trust. Right? It's really the only way. There's no way to promise that there's gonna be a guaranteed amount of accuracy increase. So I'm sure everybody wants to hear something like. We can guarantee that you're gonna have x amount of accuracy improvement with, by using a particular forecasting tool. But kind of just a misrepresentation of what's going on. You can probably use some of these, the AI tools that will come out in the next few years for forecasting to, to really help you address the volatility in what, in a, non-stable environment where you do have all these different things happening and everything's changing. You've got async work where you got cases that turn into phone calls, that turn into chats. Some of these tools can really help with that, especially if things are volatile. it may be that, and you never can un black box'em, they're, it's just, you're either gonna have, it's either gonna work or it doesn't, and you'll just have to, you know, people are just gonna have to figure out whether or not it works for them. By trying it out then giving feedback to the, vendors that you're using their tool and say, well, it, it didn't work and here point, let me show you where it was bad and potentially why. but weight and averaging may always work out for some of your more stable places. if weighted averaging is still a really successful way to do it. There's a reason why we've been using it for a long time. There's a reason why Erlang worked so well a really long time till we got to a multi-skilled environment. And then, you know, then now weighted averaging is a good way to, pull in a a good forecast. That doesn't necessarily mean it translates very well into the number of people you need to have. And I will tell you one of the biggest problems I had working in this users not being able to. Wrap their head around the fact that things like erlang are not a headcount like you, like when you, some vendors call some things, certain things, other vendors call it other different things like and so the terminology can get all kind of wacky. One person's expects this term to mean the same thing. It doesn't here and it doesn't. But in general, the general concept of a headcount is different than what we would consider like a full-time equivalent of workload. Full-time equivalent of workload is not a headcount that you staff to, because there's all sorts of other things that happen that's just if that person was working the whole time. So that's one of the bigger challenges we dealt with, and I dealt with many, times that there's just things that communication wise people aren't wrapping their head around like I. difference between what a headcount is and what potentially what an erlang agent is. Why you can't have, so depending on your environment, why you can't have a you can't have 80% of calls handled in 20 seconds with a five when staying under 5% abandoned. And, also staying at a particular occupancy rate, right? Like your occupancy is highly dependent on what your abandoned rates are and the patients of your callers.'cause if you've got a lot of people calling in, if your folks are on other calls, then their occupancy is really high, then you're not gonna be able to keep them from abandoning if the patient's as low. the only way you can keep them from abandoning is to just have people sitting and available. That means your occupancy goes down and trying to those trade-offs to some people is, has been very difficult, especially when you've got an executive who says, this is what I want. Give me a forecast and schedule that says 8% of calls in 20 seconds. It's less than 5% abandoned. I don't wanna see anything less than 85% occupancy. And you go, your callers generally only wait around for about 30 seconds before they hang up the phone. What you just asked for is literally impossible. It's not happening mathematically. It's happening.

Irina:

I agree with you here. Especially when you are talking to people that are not necessarily users, but they're the one who are releasing the budget. It gets very tricky.

Rich:

Yep.

Irina:

guess where I'm coming from is often the lack of transparency, communication, even understanding of current pool of employees on a vendor side, how their own software works and, I'll give you example because this is something that I. I, walked out of a call. I, would admit it. I, couldn't handle that. It was just like a huge, no, I'm not doing that for me is I got a vendor coming after me quite a lot to, to review their software and provide feedback. So I ended up spending, spending some time with them. I gave them a little bit tips and tricks. Okay, this is what a user would want to see. This is what's important for us to do our job. And then on my last call there was the I don't know the exact road ahead of product team, let's say. And one of the engineers, and they showed up and they was like, okay we would like to ask you why does our software works in that way? And I was like, confused. Like I, I literally couldn't understand the question, so I was like, what do you mean it's your software? Yeah, but we don't know why is it done in that way? And I was like, listen, if you're coming on a call with me and you're telling me as a head of product that you an engineer, that you have no clue how your software that you're selling is using, then we shouldn't be talking anymore.

Rich:

That was the engineering person or was an actual product person?

Irina:

Product person, an engineer in the team,

Rich:

So, here, this is the reality is that these software companies, some of them are large some of'em not so much, you can't hire ev every single person you hire. That's not necessarily going to have experience for, especially from an engineering side, it's not gonna have experience in WFM. Right? Engineers are engineers and as long as they can do the code and they can

Irina:

disagree. They don't WFM specialists. They do need to know what they're doing and they do need to know what they're communicating.

Rich:

I would agree with you a hundred percent that they should. I'm saying that they don't, because that's really tough to find. It's really difficult to find. I've spent a lot of time working through engineers. It's hard to find engineers who are gonna have deep WFM experience and knowledge. And when you find them, usually really expensive and your budget isn't gonna let you hire that person. are some that are really good that really know what's going on, but as organization, organizations grow, you gotta hire people into roles that may not know that type of thing. now the product people you would hope have experience with WFM, right? You hire, if you have a WFM product role, you would expect that, people would know WFM pretty well. They may not need to be a super big expert to get to, to, work through what a product role would necessarily do. But it certainly is a big benefit to having people who have a lot of WFM experience to do that. It is also the case that they're going to hire people who do not have all of that experience. You're gonna find that, the WFM vendors are gonna hire people who might be product people, but they're not gonna necessarily have a ton of WFM experience. Again, WFM experience, people are gonna be more expensive, they're gonna cost more, and they may not have the budget to be able to do it. I, listen, I completely agree. I think that the company should just pay it out and take the people who have all the experience, so that you can get the product you want and the people that argue on the customer's behalf and be the voice of the customer. I completely think that's the case. But, you know, there's a lot of decisions in corporate world that get made that are numbers on a spreadsheet, and they're not they're not, well, that's.

Irina:

I, I think we're mixed it up. I, fully understand you and we all start somewhere. We all need to learn. I do get that part, but for me, if you are, that's the same issue that they have with solution consultants, right? If you are a solution consultant for vendor A and you are training people how to use that software, if you don't know how the software is using, how the hell are you training me? And it does happen. So I always say, I want you to have workforce management experience because then you can understand my challenge, my question, and then you can translate your product knowledge and how your software works into that challenge. But if you don't have workforce management background, the least I would hope for you is understand your tool. That's the least. Right. And this is the challenge for a lot of us when we say, you know what, we see the schedule that has been produced by the system and we have the feeling that email is not prioritized. So we would like to check with you how emails phone emails, phones, the chats and so on, prioritized. How is the service level taken into account? And usually what happens is phone takes priority. Okay. Are you sure?'cause it doesn't look like that based on the schedule that's produced. We, think so. And there is no one that knows that because a lot of these tools are legacy tools that are built 25 years ago. Somebody back in 25 years ago thought it's a good idea. It worked then for debt market and it remained the same. And it's too expensive right now to fix it. So this is why we're rolling out those new features when we're not fixing the basics.

Rich:

I cannot speak to all of how the vendors work, but I can tell you that I have worked with many pe with people who do know those things. They can tell you exactly how they get prioritized. I can tell you all the math that happens behind them, what the algorithm is doing, every bit of it. The people who write the algorithms and maintain them, do know. I've been on the phone and many times with and with folks explaining that to users and had users go, oh, okay, things click. Like when you get somebody who can really explain it, in depth and well, and go through the math and go through how the algorithm will make decisions and how, and all of that stuff. And that's very, helpful. It's usually like one person at a company though. So all your solution com, all your solution consultants, all of your general people doing training and support and all of that, none of them will know those answers. They might have some tangential information that might help, but they are not gonna have that level of knowledge. So deep inside what the application's doing, like I said, you'll get one, maybe two people, maybe you'll have a senior software engineer who is writing the algorithms who could explain things to you. You have potentially a really senior product person who has just been in, you know, lived that for a really long time and can explain how all those things work. And then you've got maybe a couple other people who can speak to it pretty well, but it's not gonna be the general population of any of these companies because it is way too complicated there. There's so many things going into how those things work. You're just not, they're not gonna be those people there. There's only gonna be a number of people you can count on your hand if you're lucky.

Irina:

Again, I'll give you that. It's WFM system as such. It's a very complicated beast. It takes the information into account from so many different places, and the more restriction we're putting into it, the, more it like gets weirded out. What do I do now? And it spits out some result that might be based on gazillion simulations, and you won't be able probably to provide information to that level to majority of people. let's face it, it's too complicated, but at least some more in-depth information. I think as w FMRs are kind of intelligent people, I would say that would require to understand that information. For me, it's like, what do you do if that one person in that company leaves? Who knows how that system works? Like no one. What do the company do then?

Rich:

I couldn't tell you. I mean, I assume that's probably a case with a lot of companies where you have one person who is really, familiar with stuff and they're kind of a linchpin where if they're pulled, you the, amount of experience and knowledge on the tool is gone with them and you can't get it back. Don't know. I, you know, it's a concern that probably a lot of vendors should have. I don't know how they mitigate it. I don't know. I can't say that I can speak to how they mitigate those type of problems. Know that you should demand them. I know that you should demand to speak with the people who know, so I know that the thing is, that for sure when you're engaging with one of the vendors. Just demand to speak with the people who really know, because the loud, obviously the way that all of this works within your customer is the squeaker the wheel, the more attention you get. So If you, just the way it is, you know, if you make a lot noise about how you wanna understand how these things work, you don't, you're not, obviously they're not gonna turn over proprietary information about how algorithms work or anything, but they can give you a lot more detail. But you're not gonna get it through people who are frontline support. You're not gonna get it through people who are, you're not even gonna get it through mo, mainly the engineers, you're probably gonna need to speak to higher level product people who've been there for a long time, something like that. Maybe engineers, depending if they're the right folks, but, you know, sometimes sometimes you need to, the, a lot of these companies. It makes sense. You don't always put engineering folks on the phone with customers.'cause

Irina:

Yes.

Rich:

will tell you things that will say things that you don't necessarily want them to say.

Irina:

Yeah. Or will not have the most customer friendly way of explaining stuff.

Rich:

Yeah. It's the most friendly way to explain it. It's just oh no, that doesn't work. Right. It's oh, well

Irina:

Yes.

Rich:

got, do have to watch what you say. I mean, you are a vendor, you're trying to keep people as a customer, so you're not, you don't, you wanna, you definitely are going to watch how you frame every answer, but that's natural. I, I wouldn't expect that any, like even when you're a contact center and you've got a, like if you're a BPO and you've got a customer, you still have to watch how you frame every conversation about how you do things because you're not going to tell them that doesn't work or that you don't care or whatever.

Irina:

Okay. We're way past our usual 30 minute recording, but I do have a final question for you. Yes. Because obviously now, I'm enjoying this conversation so much that I'm actually having a thoughts of doing a second part with you because there's just so much that we can talk about. But for this question, I want you to be honest, like very honest, you really have to promise to be honest, because this is one thing that all of us are wondering, you know how the majority of vendors do have that kind of idea portal where if you are existing customer, you submit your wish, your idea, and then it ends up with the product, whatever it is place. And then you get to decide, okay, can we do it? Shall we do it, when do we do it? And so on, right? That's usually how we are trained from user perspective. Just submit it and it's gonna land with the product. Does it land in your bin?

Rich:

So, I can only speak from what I did, right? I can't, again, I don't know what other companies do. I had a team meeting where me and the product managers that reported to me took an hour every single week, and we looked over every single new idea that came in. We reviewed them and we tried to understand whether or not it was feasible for us to do.'cause listen, trust me, you get ideas that are like, and that's not happening. You're crazy. You also get stuff that's really good, and we do look at those things. And, we would review them and see the feasibility, see if we felt like we could put it in a backlog. Sometimes they're really big and it's like a, you'd have to do, we'd have to do an entire strategy effort to say, you know, we're gonna do this thing where, you know, some of the ideas span this, crazy level of a gamut of all the way from hey, just automatically fill out the, like the number when I type eight, just fill out eight colon, zero, zero in a field because it's a pain in the butt for me to have to type eight colon zero, zero to get to eight o'clock. Which, you know, that's a one day piece of. Effort for development and versus, Hey, look, can't you just have AI like review all the schedules over the past like eight years and then tell me what the best schedule would be. It's oh yeah, sure, we'll just turn that one right out. Right? But we did, we reviewed those, I reviewed those in my team every single week, and we put them into buckets and said, listen, we're likely to do this one. We're not likely to do that one. I tried to provide as much feedback to folks that as I possibly could about whether or not we really felt like we would do it or not. And it, it always is rough to get that feedback that we're just like, yeah, we're not, gonna do it. But I, figure the feedback that we're not gonna do this is better than it just going into a pile and getting forgotten. For, the, to tell you. Now, the thing about the ideas portals is companies are gonna have like a. Policy, like a threshold to say, you gotta cross X amount of votes on this particular idea to there has to be a number of duplicate ideas to say, this represents a large number of the user base. idea. One idea With one person who said that I want this. What does that mean to you? Because I've got a thousand of those. I've got a thousand ideas where I have one person say, this is what I want. And nobody bothered to comment on it. Nobody bothered to vote for it. Nobody bothered. You know that There's not even duplicate versions of it. Why? What would, make me prioritize that if one person says it, 200 people the same idea in, or they vote on the one idea for something. there's tons of comments and there's tons of activity on it, and it's constantly being voted on. It's constantly being commented or co or, same ideas constantly submitted that those stand out big time. Oh, sorry, my microphone. Those stand out big time for for product people to, know that's actually something good. So again, I can't speak to everybody how all these product teams work, but if that happens for us, we took that into major consideration because it's a big win. If we deliver that feature, then we can say, we delivered the most popular idea out of our customer user base. And it's the only, it's the best way for you to get feedback without having to necessarily get on the phone with somebody and

Irina:

Okay. that's, great. Majority of cases, I know that when my teams got to submit ideas, usually they didn't necessarily hear anything back. So this is my question, like in what time would you provide feedback to the idea submitter? Is it like immediately? Is it in a month that you say that you have noticed it? Do.

Rich:

Well, we would try to do it every single week, but it depends because some of them do not. Some of them we just leave because we go, okay, it's not a bad idea. It doesn't have enough attention to, it's not a bad idea, but it's not necessarily a, an idea that's going to get any traction because no other customers are asking for it. And so we'll leave it to see if it gets votes. If other people are, interested in that same thing. have a good way to tell. be honest, you're looking at it and you go, that doesn't sound like a bad idea. It doesn't sound like necessarily a great idea, but like it's out there Now. Is anybody else gonna give it attention and say, yeah, We, that we do. once it, generally speaking, once it gets enough attention, then it gets a, more legitimate review. Like we'll do, I'll do a weekly or biweekly review and we'll look at all of them and go, is this something we can do with something now? Or is it something that we need to just see, let it cook for a while and see if it gets garnished some attention. Recommend that your use those ideas, portals, and that they're active on them. Because we honestly, it's not just the ideas that we see, it's actually the people putting in the ideas.'cause we can look and see who's putting them in and the people that put in the ideas. If I see you putting good idea after good idea, I start to take your specific feedback is being important.

Irina:

Hmm. Okay. I like that tip.

Rich:

Well, and I can't there just the truth. You see that there are certain people that will submit great ideas all the time and you're like, gosh, that makes so much sense. You start to realize anytime you see an idea by that person, it's gonna be a good one, take it into account, even if it hasn't got as much attention because you know that person is potentially like a consultant or there are like a real power user that's gonna say, look, I've got a good idea about anybody trying to do these exact same tasks, is going to, this is something that would make their life easier.

Irina:

Okay.

Rich:

I would definitely encourage your folks to use those as much as they can and comment on, I, I don't know, like a lot, I don't, I know that there's multiple companies that, that use specific tools, but if they have a comment system on them, engage with your other people that are on those, have those conversations and talk to people and explain why it's actually useful, I, I would find as a product person, we, somebody would say, Hey, I got an idea for something. And I would go back and comment on that idea and say it, okay, I see what you're saying about the idea, but what's the actual problem you're facing? What's the challenge you got? Why do you want this idea to be there? literally nine times outta 10, that was the end of the conversation. They'd never come back. They would never come back and say, this is what I was, this is the problem I'm having. This is the challenge I'm having. This is why I want this. That would be it. Literally nine times outta 10, at least there's barely any, they would throw the idea and go, okay, I put my idea in, I'm done. And. Lot would come back and be like, look, I am actually interested in hearing about this idea more. And we would assume that the forum would be used and it wouldn't. It would just go, then it would go to die because we'd say, well, we try to reach out and ask you what more, or you know, ask you questions about it. And that would be it.

Irina:

No thi this is a very fair point because sometimes it's just to basically showcase yourself as someone who has been proactive, but then equally so, if you guys from vendor perspective are showing interest and there is no follow up, then I do understand that the priority on this will kind of disappear. So that, that's okay. Final thing, I promise. It's just that we have so many angles, so much to talk about. One thing that I would say I recently worked with a vendor and this is kind of repetitive type of a situation that I'm encountering. And it was a specific retailer and it was a great tool, a really great tool, but it was a great tool designed for the us. It's a vendor US based vendor. And one thing that I keep on saying to absolutely every single vendor or every single project that I'm on, we do have completely different requirements, even from a legal perspective. So you guys are very business driven. In the us, in Europe, we have very employee driven legislation. So sometimes what you develop and it's great, cannot be applied here without certain restrictions and. If you are a vendor who would like to take a bigger percentage of the market, there should be much more focused on how things actually need to work here. But I understand that if you're comparing size wise, you know, you have ideas from the US versus some ideas here, but that one or two ideas here we'll make for the whole market share. Because we can't bend those rules. We simply can't by law. So that's one thing that it's a bit of a concern for me. Luckily, the vendor that I was working with was spot on. They literally took every single thing on board and make sure that two is compliant. But that's the thing that I'm seeing that sometimes we try to bend the tool to use it in a way that it's not initially designed for because we're missing those kind of requirements.

Rich:

Sure. And you mean you, said it yourself. I mean, generally speaking, it's gonna be a, If you're, if you've gotta do let's say you had to develop some sort of scheduling feature to adhere to labor laws. Features are big features by the way. I don't know how familiar, like any scheduling feature is a huge feature. Anytime you gotta add anything to the scheduling algorithm, it is always going to be ton of work and it's gonna be a ton of QA you can so easily break things that will cause other problems. So it's a bunch of work. So they'll do you know, an ROI assessment and say look, we're gonna invest a bunch of money in developing this new scheduling feature to help with LA labor laws in a particular region. what's the impact? What's the market look like? How much can, how much of that pie can we actually cut off if we do that feature? And if it looks like enough, the vendor will do it. that's generally what'll happen. But if, it doesn't because there's, but like you said, there's potentially another feature in another market that would get more money, then that's potentially the one that gets prioritized. I would definitely say that regional specific features are important that need to be done. obviously things like localization, if you don't have a, certain language supported, then you can absolutely lose business in this particular area. But even sometimes simple stuff like just date formats. Like you didn't support a European Day format, so all my agents had a hard time reading it. or you know, from the forecasting side, like when you talk about what an FTE actually is, well a lot of, I've seen a lot of these folks where, well, we consider an FTEA 40 hour work week. Well guess what? In Europe it might not be, it might be a 37 and a half hour work week. So every calculation that you do for me, now, I gotta go back and adjust, which makes it a royal pain in the ass where you should be able to say no. I can configure what my FTE calculation actually is. So I 37 and a half hours is what we consider one FTE for a week or a month, especially a month. This is the other one where a monthly FTE in, in Europe was very much different than one in the us.

Irina:

And still one of the pains that we're facing, literally on the market, it's, we have to bend every single tool.'cause it's mostly designed for weekly work and not for our, especially in eastern in Europe, it's, very difficult to get this right. But thank you so much Rich. I know that I've been giving you a lot of hard time. My intention was to address all of the frustrations, all of it that we're feeling, particularly so to give you the opportunity to. Humanize product teams and what's happening behind the scenes and how we are working and the pressure that you guys are facing.'cause this is something that we're not seeing. So for me, it's always a good idea to show, okay, you know what, it might look very easy on our side, but this is what is actually happening. So thank you so much for basically be the, sponge for all of my frustration of this conversation. Thank you so much.

Rich:

Thank you very much for having me here. I'm definitely happy to come back and chuck for another

Irina:

you'll be coming back. Trust me. Thank you so much and chat soon.

People on this episode

Head Shot

Irina Hollatz (Mateeva)

Host

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.