Your Bank Needs a Minimum Viable Process [Podcast]

September 5, 2016 Iris Maslow

 

Minimum Viable ProcessIn order to be successful, a bank relies on processes. However, it can be difficult to build one that addresses a real problem and actually gets adopted.

In this episode, Dallas Wells and Jim Young explore how bank’s can develop a Minimum Viable Process (MVP) to achieve success.

   

 

Helpful Links

Podcast Transcript

Jim Young: Hi and welcome to the Purposeful Banker podcast. The podcast brought to you by PrecisionLender, where we discuss the big topics on the minds of today’s best bankers. Jim and Dallas here as your host again this week. Thank you for joining us. Dallas, in this episode we’re going to talk about your bank’s MVPs. No, not talking about your Michael Jordans or your Mike Trouts. In this case, we’re talking specifically about a post we found at the Pilot Blog called, “Start with a Minimum Viable Process”, that MVP. So we thought this was worth discussing. The term MVP, Dallas, has become a bit of a buzzword in the software world. For those who haven’t been subjected to it, can you kind of walk us through the basic premise?

Dallas Wells: Yeah, so in the world of software, and I think we’ve probably mentioned it on this podcast before, but the term MVP stands for a Minimum Viable Product. The basic idea is that instead of going and hiding away in your cave for two years and building the perfect piece of software, and then you roll it out and hope that everybody likes it, instead you find the minimum viable thing that you can ship. So what delivers kind of the basic value in the simplest form possible. That way you can figure out if you’re right or wrong in a faster, cheaper way. Once you verify that there’s real value there and that people really use it and get something out of it, and are willing to pay for it, then you can start adding on, little pieces at a time. You add a new feature, again, the minimum version of that, ship it out, figure out if it works or not. If it does work, then you start to tweak and improve based on real user interaction.

Become a huge thing in the software world, there’s whole methodologies and processes around building software using that as kind of the foundation now, which I agree is leaps and bounds better than the way it used to be done. But that, as we said, a buzzword there, it gets thrown around a lot and including now being applied to not just products but to lots of other pieces of the business.

Jim Young: I’ll be honest with you, I’ve got some natural skepticism about a little bit of this. We’ll get to that in a bit and maybe I’ll be speaking for some bankers on this when I voice them.

Dallas Wells: I think you will, yeah.

Jim Young: I’ll be their voice. Then this post takes that MVP concept with the product concept and applies it to processes. Why that connection, other than the fact that you can say MVP again?

Dallas Wells: Yeah, well, it starts with a P so it fits, right? Processes, and we come across this in our own business really, where we have a big chunk of the team is software engineers, so they’re building an actual product and it applies directly for them. The rest of us in the company though, we’re not building the product, but we’re building processes around that. So we have a sales and marketing team that’s building a whole sales funnel and then we have a client success team that delivers the product and there’s tons of processes around that. How do we get a client onboarded, what are our regular touch points with them, what do we do at renewal time? Everything has a step-by-step process to it.

The same concepts apply here of don’t try to make the perfect thing and then find out later in a very painful way that you were wrong. Instead ship the minimum version of it, start with a very simple process and then build on it as you learn.

Jim Young: The post is pretty short and sweet and it’s definitely worth your time to read. We’ll try to give you a quick rundown of it. Dallas, one of the first points they hit on is this idea of no, don’t try to overhaul the process all at once and that creates a couple of problems. Can you talk a little bit about that?

Dallas Wells: Yeah, it mentions two specific threats. Number one is it takes longer to find out if it worked. Basically, think of every new thing that you do kind of as an experiment. You make the best decisions you can, knowing what you know at that time, but you don’t really know until you release it into the wild. In our case, we try something with clients. In a bank’s case, you try it with your customers or you go through your process internally and then you’ll find out where the holes are. But rather than spending a whole bunch of time and effort trying to make it perfect, instead you just try to do a shorter version so you can get to that answer sooner. Are we on the right track here or not?

The second big threat is, of course, if you had this completely overhauled process, it’s a lot more difficult for your users or your employees to actually learn it. So if you have this giant complicated 50-step process that’s brand new, it’s going to be really complex. Whereas, if you have a very simple version of it, or you just change the first piece of this longer process, the changes are more piecemeal and it’s a little easier for them to digest.

Jim Young: The next point gets really counter-intuitive. They say don’t sit down and document the way you’d like the process to look. How does that work?

Dallas Wells: Well, I think we all have a tendency when we’re putting down a process and we’ve overhauled a bunch of ours in the last year or so on our client success side so we’ve been doing this over and over again, there’s this tendency to say, well here’s how it would be perfect, here’s the point on the horizon the way we want it to be, so let’s write that as our process, when really maybe we don’t have all the tools in place to do that, or it is that kind of overwhelming too much change all at once. The point that they make in this post is document it as it really is. So if there’s shortcuts and workarounds that you’re doing that you know are temporary, still document them that way because that’s how people are really going to do it and then you can always come back and clean it up. But you don’t want to try to create the perfection that you realistically are not quite to yet.

Jim Young: All right, let me play Devil’s advocate here a little bit because I didn’t put it in a bank term. Let’s say, the process we’re talking about here is, for our purposes here, the commercial loan approval process at our bank and we can tell it’s just, it’s really screwed up and it’s taking too long and there are too many loans that are getting rejected. Would it work fast enough in some situations that you really have something that needs to be changed significantly?

Dallas Wells: Yeah, so this is where – and you’ll see some OCD tendencies from people of wanting to do things in the order of the process. Well, we have to start at the beginning and we fix it in order. Step one has to be first. When, in reality, it’s more of a triage thing. So you find the biggest pain point and fix that, where can we put in the least amount of effort and get the most value out of it. So you start at the biggest bottleneck and fix that, and then you move onto the next one. It would be a little slightly disjointed in some ways there, but you get the most bang for your buck.

One of the other things that the post points out is you need to figure out where you need to go, so you’re documenting your process, sort of your steps that you’re doing. Those need to be reality, that’s the as-is. But you do need to know what that point on the horizon really is. So if it’s a loan approval process, right now it takes us six weeks. We want that to be three weeks. Here’s the systems we think that that will take and here’s the things that we think will maybe be reordered. That’s kind of in a fuzzy way what we expect to happen, but here’s the small thing that we can do first that addresses the biggest problem. That fuzzy picture out on the horizon will keep getting clearer as you get closer to it, right. You’re going to learn every step of the way and figure out better how those pieces fit. But you do have some general sense of direction, you don’t just charge off into this with no idea of where you’re going. It’s just that it’s not a predefined path that you can’t deviate from. It’s one where you plan it as best you can and it’s going to change as you go, but you do have some sense of direction when you start out.

Jim Young: Another Devil’s advocate question here then is this idea of sort of – it feels a little bit sciency, a little experimentation-like, okay, we’re going to do this, see what happens and then change things. What if you’re making mistakes that have, not to sound dramatic, but sort of irreparable effects on your bank?

Dallas Wells: Well, really, that’s the whole point of doing it this way is you want to take every change that you make and, as this post says, start as small as possible. Take it into these small little pieces. What you’re doing is you’re taking an experiment that is an acceptable level of risk. Within a bank, let’s say that the lenders have been putting their own deals into the underwriting system, so they’ve been spreading their own financials basically. We say, wonder what would happen if we just had the loan assistants do that. We’ll give them some basic training on how to do that and we’ll have the admins just put in the initial spreads and then it gets moved on down to the underwriting group.

Instead of saying, hey, we want to completely change around everybody’s responsibilities, let’s do that all at once. That’s where your risk is, is that you’re going to miss some little detail there because you’re doing 100 things at the same time and you don’t think about, well, if we do this, there’s this unintended consequence over here. You do it in small little manageable chunks where you can actually see what the risk is and make a decision, is that okay if we try that. So you can take one small little group of your lenders and say, hey, for you all, you don’t do your own stuff anymore, you have somebody else put it in there. Do it for a couple of weeks and see. Can they handle it? Is it faster? Is it slower? You learn from that, and then if it works, you roll it out to a bigger group. So it’s these small little manageable things that you try.

Jim Young: Okay, all right, you’re slowly convincing me here, which is [crosstalk 00:10:52].

Dallas Wells: Yeah, making the hard sell.

Jim Young: We talked a little bit, for obvious reasons, the loan process is one of the things that we talked about. Are there other places within a bank that they can put this MVP concept to use?

Dallas Wells: Yeah, I think there’s tons of them internally and, again, we’ve talked about this a lot. All banks are feeling this pressure, we hear it all the time of you’ve got to move faster. By moving faster, that simply means be more responsive to your customers, so all of those customer-facing processes that we have. How long does it take us to get back to them with pricing? How long does it take us to approve the loan? How long does it take us to then document that loan so that we can close? Really, the big picture thing that we’re trying to shorten is the first time the customer asks for something until we get to the closing table with a deal that they’re happy with. Right now, that’s a really long time in just about every bank out there.

All of those little – that big process is really overwhelming, but it’s made up of a series of smaller processes and each one of those is really prime candidates for this process. Break it down into little pieces and say, what are the small pieces of this that we can roll out something new. We don’t have to do this kind of what we call a heart transplant, where you just swap out everything all at once. What are the small little pieces that we can take little building blocks, start where there’s the most pain, fix that and then move on to the next one.

Jim Young: All right, so let’s say I’m a bank and I’m thinking okay, maybe this MVP thing is worth exploring. Are there other resources out there to help a bank that wants to try this approach?

Dallas Wells: Yeah, there’s lots of stuff that’s out there that you can learn from and really where this MVP concept came from is from the Lean Startup book and then the series of books that came after that. So we’ll put links in the show notes to that stuff. I think that’s a really good starting point. But the software world, compared to where it was a decade ago and bankers know this pain first-hand, of you ask a provider for something and they say, well, don’t worry, it’ll be in the next release, which actually is 18 months away. Then by the time you actually get it, well, that thing doesn’t work or it’s not exactly what we asked for. By the time you get around to the next cycle, you’re years down the world before you actually get your problem solved.

What software vendors now can do, at least the ones that use this much more agile methodology, is does things get turned around in matters of days instead of thinking in years or months. Like our company, we don’t do releases, we don’t do versions of stuff, we have basically a continuous deployment. We push code every single day so that we can make small little tweaks. It’s this same concept of small little manageable changes that we can make, instead of Version 7, that’s going to be the answer to everybody’s problems, that’s the one that fixed everything, just wait till we’re done with it.

So, the software world I think is where you’re going to find things that you can apply back to the bank, rather than thinking of it in the traditional banking process change, which, frankly, I’ve been there, it’s painful and it hurts. Just think of breaking everything into blocks and then you can apply some of the Lean Startup stuff. We’ll, of course, have a link to this post that we found here and a couple others that talk about minimum viable products. Just substitute product for whatever you’re building. Is it a process, are you building a loan file, are you building a relationship with your customer? All those things can be broken down into that same concept of small manageable chunks, try something, see if it works and then build on what does work, scrap what doesn’t work. But all along the way you’re just learning more about what’s the best fit.

Jim Young: All right, makes sense. Makes sense to me. Again, those resources, we’ll have links to those in the show notes for this episode. You can always find those at precisionlender.com/podcast. That’s all that we have time for today. Thanks to all of you who’ve taken the time to listen. If you like what you’re hearing, make sure to subscribe to the feed in iTunes, Sound Cloud or Stitcher and we love to get ratings and feedback on any of those platforms. Thanks for listening, until next time for Dallas Wells, I’m Jim Young and this is the Purposeful Banker Podcast.

The post Podcast: Your Bank Needs a Minimum Viable Process appeared first on PrecisionLender.

 

Previous Article
Scaling the Wall of Scalability
Scaling the Wall of Scalability

Has your pricing tool run head-on into the Wall of Scalability? If so, here are a few things to consider. ...

Next Article
Level Principal Pay as an Alternative to Standard Amortization
Level Principal Pay as an Alternative to Standard Amortization

Sometimes it makes sense to go away from an old standby like the standard amortizing loan and instead offer...