Low-Code in Finance: Homepoint's Path to Strategic Business Impact

Low-Code in Finance: Homepoint's Path to Strategic Business Impact

Show Video

- We appreciate you joining us today. Hopefully you had a very good morning keynote as well as lunch, and we're excited for you to join us for our session, The Path to Strategic Business Impact. My name is Chris Wherry, and I am a Vice President of Strategic Accounts here at Appian. I've been with the company for over 18 years, the first 10 of which I was part of our customer success team, and the last eight, I have had the privilege of working with customers like Homepoint up here to help them identify and align impactful use cases to the Appian platform. I'm welcoming Mona here on stage. I'm excited to have her as part of the discussion today.

So Mona, would you take a quick chance to introduce yourself as well? - Sure, hi everyone. I'm Mona Samaha, I oversee business transformation at Homepoint Financial. Homepoint is the third largest wholesale lender in the country. We've been with Appian a couple years now and actually my prior employer was also a customer of Appian. So we are happy to, again, work again with Appian and build our workflow solutions.

Homepoint is a newer mortgage lender founded in 2015 and we went public in February of 2000, sorry, 2021. We are based in Ann Arbor, Michigan, and our primary emphasis is on third party originators. We have over 8,500 brokers across the US and we fund loans in the 50 states, not over, so in the 50 states. - All right, well, I'd like to start today's session, just kind of level set on what the topic that we're gonna discuss here today, and it's all about delivering to impact.

So after my 18 years, it is very clear to me that what we sell at Appian is this. Now I was working really hard for those of you who know me to figure out some way to drop a Jonas Brother's reference here, but unfortunately it was a really big stretch, I'm unable to do that, but this is an easel and a canvas. And you know, you may be saying, "Well, geez, I can go get this at a local art supply store "for really cheap, why would I need to get it from Appian?" But more it's just the symbolism of that Appian is really a blank canvas and that you as the executive or the product owner or the developer, you not only have the opportunity, but you have the duty to build the right things as part of your application. And when my slides come back, I'll be able to build out this amazing animation. (audience laughing) So you have not only had the opportunity, but the duty to build the right things.

And why am I talking about building the right things? Well, the right things that actually are gonna deliver the impact that you want to have to your organization. And man, this animation just ain't working, I don't know. Wait, wait, we'll see how the tech works over here, 'cause the animation is all this slide. I'm just gonna tell you that it's like I'm showing off my PowerPoint chops. - There you go. - There you go. All right, so that's your paintbrush.

So to help you build your masterpiece, 'cause you're painting out your masterpiece, Appian is the pallet of options and we are providing you a lot of powerful options to go after the hardest use cases and be able to do that at speed. So think of like painting by numbers versus completely freehand. Easier said than done though, I'm gonna introduce you a concept of delivering output versus delivering outcomes. So I'll start on the output side.

So have you had a project team talk about their status and how they're coming along in these type of terms, story points delivered, releases live, they're ahead of schedule, maybe under budget. Those are great things, but what if I told you that the whole point of the application and how they got it justified was they were supposed to deliver $10 million in cost reduction and they were almost at the finish line, according to story points, and they'd only delivered 2 million. Delivering outcomes is what the project teams need to be focused on, and here's some other examples, 30% more revenue, improvement of customer satisfaction scores, maybe taking a process that's time is of the essence and reducing onboarding by 10 days, those are the really important things. So to kind of full circle, step to stage, today's session's all about, and what Mona and I are gonna do, we're gonna provide five tips for really how to avoid the output trap. And the first tip, (audience laughing) the first tip, hello, hello, is this working? No, we're having some more technical difficulties.

Ah, there we go, start with the outcome. This seems easy, right? Start with the outcome, we were just talking about it. Well, each of your projects should have some sort of outcome or North Star that's guiding the project team to ensure that they're building features and capabilities that relate back to that outcome they're trying to achieve. And so you say, "Well, how do I find that? "I'm the project team, I don't know those.

"Where do those come from?" Well, one of the ways is, think about justifying investments. Most of the companies like at Homepoint, they'll talk about in a second, but they go through a process where they have to actually justify their investment. They have to come up with a business case and convince people that are writing a check that, Hey, we're gonna go do this thing, It's gonna deliver a result. And that result that they're trying to deliver is the outcome that they're hoping to achieve. So I'm gonna pull Mona into this discussion, I'm really happy to have her on stage.

So can you maybe talk about how the process works at Homepoint? How do you guys justify investments and how do you ensure that that project team kind of knows what outcomes you're driving towards? - Sure, absolutely. So as you said, it is starting with the outcome. So early on, as early as when we're developing and creating our roadmaps, we start with some discussions around what phases of work, what do we want in our roadmap and within our areas of focus, how is that gonna help the organization hit those targets? So within each area and our areas of focus, I'm sure like many of yours, efficiency and quality, we also have partner experience and market share. And as we're building our roadmaps, we have a lot of discussion around within each of those area of focus, those targets, those desired outcomes.

And that helps us to prioritize what work we're doing with the sequencing of work. Again, a lot of data, a lot of analysis, but really starts with the discussion around outcome. And then further, as we get into planning around the feature level, we kick off with those discussions around success metrics. How do we know that this planned feature, this planned work is gonna help us hit those areas within our targets.

And we challenge the teams to ensure that they're building those capabilities that are gonna get us to those desired outcomes. And finally, we continue to just communicate that down, not just at the beginning and the onset of phases of work and kick off, but also when the work is done and completed. So you close the loop and that's something that we've actually started to do a better job of, and something we learned through the process is you do need to go back to the teams so they understand just how those capabilities got you to your desired outcomes. - Great, all right, so you have your outcome, your teams have their North Stars and now they have to go figure out what they need to build, what features, what capabilities they're gonna help them deliver that outcome. So back when I ran customer success for North America, one of the key differentiators that I always talked about was that we were really good at challenging customers and asking the why.

I understand you're asking me for that set of capabilities or features, but why, and how does that map back to these top level goals or outcomes that we're hoping to achieve? And the result of being really good at that is that you are not gonna over-engineer the solution, you're not gonna gold plate it, you're gonna get the solution in the hands of users faster, which we all know getting the user to experience, they can give quicker feedback loops, you're more taking small little turns to eventual destination and ultimate goals. So, the customer success team at Appian has matured a lot in the last eight years and why is what we started with, but we've really built a lot of tools, techniques as part of our improvement of our methodology. And we build things like customer journey maps or impact maps, but really once they then determine what they're going to build, low-code is really what makes all the magic happen in the sense that I have an idea, now I can use a low-code, visual design experience and quickly show someone something and get really quick feedback. So I guess I'll turn to Mona and ask, in terms of the cultural fit of low-code, how has that worked at Homepoint and how has it helped your teams kind of co-create new solutions on the platform? - So at Homepoint, like we had very much a traditional IT, very custom development IT infrastructure.

And we spent a lot of time discussing why low-code and the benefits of low-code. And actually one of the greatest benefits was that ability to co-create, to create, visualize designs. The business engagement we found to be a challenge when they weren't able to see what you were going to ultimately provide as a solution. So having the business as part of those implementation teams, embedding them in the implementation teams and coming back to them within weeks to show them a design solution and get their feedback immediately. So is this what you were talking about? Does this solve your problem? They would also come back with, well, can you also do this? And can we add, and they get excited about the possibilities and a lot of time with development, if you're not able to visualize it and feel that there's something tangible, it's really hard to give feedback. And then you find out very late in the process that that won't work, that's not what the business wanted.

So I think that creating a culture where they're embedded in the teams, they can see the work, more tangible, more early on the process. They feel they're part of the solution, helped create a culture that was more willing to work with low-code platforms. - Great, all right, so your team knows what outcome they're driving to, they know what features they're gonna build, well, wait, should we start getting to work? Well, not yet. So it's really important as part of this process is that you understand the metrics that you're driving to and you established kind of a yard stick to me measure your success.

So at Homepoint, we recently started working with them in a new capability to help them address what they call their calculators. And it's something that they use as part of their origination underwriting process. And for each of the metrics we're tracking as part of this project, we wanted to make sure that we understood the source, that we were kind of gonna be getting that data from, if there's an existing baseline or benchmark of what that data is and how is it performing today and then we just set goals for ourselves, minimum targets and desired targets. And so this really helps us ensure that if we are gonna be building something, we kind of know where we are in the process and how those capabilities are gonna be driving that impact.

And we can test those theories out early days that, okay, well, if we build this and it shows these results, we're determined, we're successful. So I guess I'll turn to Mona and ask, from a data perspective, how are you using data and metrics to kind of drive what projects you choose, and when those projects you've deemed that they've been successful? - So very early on, we try to in our discussions around outcomes, and then what are the success metrics that we're gonna go back and measure? We tend to do a lot of data analysis up front. Now the problem is even in the mortgage industry, which is lots of data, lots of data points, we do find quite frequently that the data isn't available or we haven't captured it, so we make a lot of assumptions. And so what we do is we have enough of the data that we can do the analysis on and enough of the assumptions that help us prove the value and then we do proceed with kicking off. Now, as data becomes available, we're gonna go back and re-look at some of our assumptions.

And then also if it's work, that's planned in our roadmap, we may reprioritize. So we use data to validate our assumptions, we use data to measure our progress, measure our performance, and then also to reprioritize and possibly reprioritize. - Yeah, that's awesome. I think it's a powerful concept, what you said about, you think, oh, I have to have a baseline to get into it. But maybe the project, the first phase, you start collecting that data and then it allows you, well, this is the baseline and okay, can I now produce the outcome that I'm looking for? And you're kind of constantly reevaluating where you can get the biggest bang for the buck is really important.

- Absolutely, and there's always an opportunity that as you go into the next phase of work, if you knew you weren't able to capture that data, you actually get better at the process of like planning in advance for the data you may need or the analysis that needs to be done. So it's also a very continuously improving process through each phase of work. - That's great. All right, so your project teams, they know the outcome, they know the features they're are gonna build, they have the yard stick for measuring their success. So we're ready to build, right? We are actually, we're gonna go build it.

One of the metrics that most people forget is use your adoption. So there's nothing worse than building something that you know is gonna deliver this awesome result to your company, but people aren't using it. What the heck? And so measuring adoption is an important part of the go-live process. And so Homepoint last year, we kind of encountered this a little bit and one of their projects in the kind of the underwriting quality space, we delivered this tool that underwriters could use, we know would deliver and help improve their quality.

And we thought this could be a huge success. We get in, we go live and it's like, well, wait a minute. They're not using it, they're not using it as much as we thought, we're not getting an adoption rate. So, I guess I'll turn to Mona, 'cause you were right in the middle of this, working through those change management type issues, how did you guys diagnose that low adoption and what did you guys do about it to get it back on track? - Well, that example that Chris gave was actually a funny one because we actually built this in another prior company and it had 100% adoption. So we just assumed everyone was gonna love this tool and they were gonna use it and our quality issues, they were to correct quality issues was gonna go away. So three months into implementation, we weren't seeing the defects go down as fast as they should have and we started running some nightly reports and realized that they weren't using what we built, the team that we designed it for.

And so what we did is we started some analysis. We pulled the data to see the tools to be used at three different processes. And we wanted to see where they using it at one or two or multiple, and actually they were not using it at all throughout. And so we were able to see by person, by underwriting team, by leader, where they were, where we had the adoption issues. And there were a few people that were 100% using it, but probably the vast majority not.

And then we started looking at why they weren't using it and there was a lot of training issues. They didn't know how to fix the quality issues. So instead of escalating, they would just stop using the tool and go back to their processes as they knew them before.

So we started setting targets for each team and we knew that we weren't gonna go to 100% day one. So we started phasing in like, we're gonna get to 50%, 75 and we put it on the leadership to enforce, keep repeating the meetings. And then we increased the support for training so that they would have a place to go to when they didn't know how to use the tool. And we eventually got to the higher utilization rates. - That's great, I mean, adoption is so key. At the end of the day, it's the users and they have to love what you've built for them.

I mean end of story. Like, you're not gonna deliver that outcome unless the user loves the technology, they understand it and then it helps achieve the result you're looking for, so it's great, good story. So, I said five tips, so we're almost at tip five, but let's review it 'cause it's just repetitions, it's the only way you're gonna remember this stuff. So we have the outcome we're trying to achieve, we have the features and the capabilities we're trying to build that are gonna help us achieve that outcome. We have the yard stick to measure us.

We're making sure that users are gonna be there all along the way, and then finally the best part, right? We get to raise a success flag. We're gonna measure and manage our outcome achievement. So this is those eventual North Stars, like how amazing would it be if you had a report of your North Star that you could just measure how you were doing. And I think all too often, we think back to that output versus outcome slide, you think, "Well, geez, I'm at the last sprint, aren't we done?" Well, you may be at the finish line, there's more work to do because this is what mattered. This is the $10 million example that I gave at the beginning, that's what mattered.

That's what we signed up for this investment for, so sometimes you have to do more work to get there. So I'll kind of turn back to Mona for your final question. So, I guess, how do you guys, in terms of you have really strong data, that's helping you determine if these projects have been successful, but how do you determine if they are successful and then how does that help you determine what you do next? - So, when we plan for a specific feature, one of the things we discuss is like, well, how soon will we see the improvement? And there's different drivers for that. Sometimes you're implementing a new process and there's legacy or loans that have to flow through the process before you can realize the benefits.

So for example, we say an example would be, we're gonna be 15% more efficient in 90 days. So what we don't wanna do is wait 90 days to find out if we hit that target. So we do start some of the trending and reporting to see, are we heading in the right direction? And then we also have a new focus also on early indicators of success, such as adoption rates, such as user feedback, such as early trending. And then we get creative on how we're gonna measure that so that you're not waiting 90 days, there are early indicators of success and you just have to creatively brainstorm within the team. The data's there, it's just, what data do you wanna look at? - All right, so five tips we got there. So when you follow some of these techniques and really focus on the outcome, you can deliver great results.

And I think Homepoint is a shining example of that, they've won awards, but then even industry awards. So they were recently recognized by HousingWire Tech100 Award for a lot of following some of these methods and really doing great with the platform and achieving the outcomes they had promised to the business. And one of which is, hey, I love the first bullet point though you read it, reducing costs by $800,000 monthly. That's pretty awesome, and guess what, that was one use case. They built many things at Appian, and that was one of their use cases. So the potential is there to have to make a big splash at your organizations, but you have to keep focused on the outcome, that is most important.

So I would like to thank Mona up hear on the stage for her insights and we're gonna open up to questions, but I will say before we get there, that Homepoint is a great example of a leader in their industry that is doing awesome work with low-code. And I would almost claim to say that you guys are a leader in low-code and mortgage and the results speak for themselves. So with that, I will open it up to any questions. The mic is gonna come up here for you so we can get your question talk track. - [Participant] Oh, gotcha.

- Yeah, I wasn't gonna pull you up on stage man, but yeah. You can sing if you want. - I'll stand, I'll stand. I'm do this right here? - No, they'll record your--- - They'll record my question, got it. - Yeah, it's recording. - [Participant] What are your strategies for aligning businesses desired outcomes with like what makes a good fit for an Appian project? Like I think we all know, like some outcomes may not be achieved by an Appian solution. So do you have any strategies for like how to line or connect those dots? - So I know what we tend to do is not just start with solution and with the problem statement and what are we solving, it can be a mix of different solutions.

We typically have our rules engine paired up with the Appian platform so that we can strengthen maybe some of the quality rules. So, we don't really start with the solution. Now, how do we get the business? You said the business to? - [Participant] How do you line up like the desired outcomes with like, oh, this is a great fit for Appian? - A lot of brainstorming sessions. And in those brainstorming sessions, we don't require that we're gonna pull a lot of data. We're gonna start with just some brainstorming sessions and you'll be surprised that where you start and where you think is a good place may not be where you end up.

The other thing is along the way is we have a lot of changes in the market, the business model, you have to be nimble and not just stick to your roadmap, just because it's out in the roadmap. So you have to constantly align and realign and I think that's important as part of that's how you stay aligned with the business. - And I think just to kind of add on if I may, I mean, mortgage, when you think about, most of us in this room have purchased a house. When you think about how that transaction happens from start to that closing table, there's a lot of process and workflow, and there's a lot of complex business rules and data's flowing everywhere and there's deadlines. And so, there's really classic fits with the platform and the things that we are kind of good at. And this team, as she said, she was a customer before, so they have a really good knowledge of like where Appian strength can be aligned to what use cases.

And so it's just very intuitive to them to kind of where to apply the platform. And they have other platforms in kind of a low-code way too, that kind of help supplement, to make sure that they're delivering comprehensive solutions. Any other questions. We can't be like two ahead of time here, we got like three minutes left. Any any brave souls out there, Susan in the audience? - [Participant] You had mentioned your tech team was a build it from scratch kind of team.

How did you overcome and get them into a mindset of leveraging somebody else's technology to then deliver the solutions? - So the short answer is not easily. Our tech team, so we have our IT development team, largely custom development. When we joined our organization, our business transformation team really didn't sit in IT or in the business, we kind of owned a team really sitting in the middle between the two.

We did have to build from scratch. We were three people that joined in 2019 and we're 93 right now. So the team did exponentially grow and we did run multiple work streams because of the success we did see. Now, some of the beginning stages was getting our IT development comfortable with low-code, and the first, I think challenge we had was the questions around scalability.

There was always this concern, is low-code scalable, and that's what their fear was. And they found like it's actually more scalable than some of the stuff we've done in custom developments. So you have to sometimes go through the process of some of the myths that maybe traditional developers have. And we did that and it took some time, but it was worth the time spent because we did need the partnership with our IT development team.

So it was a start from scratch, partner with IT, and then accelerate. - But I think when you look back to that kind of co-creation of solutions, it's really, the whole team is one, right? Like there's no, when we work with them and our team's there helping, the roles are there, but it's really a cohesive team that's really marching towards that outcome, that goal that they're all working towards. I think we're at time.

I always like to deliver on time, so off we go. (audience laughing) So thank you, Mona for sharing the great story and thank you everyone again. (audience applauding)

2022-09-03 03:01

Show Video

Other news