The Roadmap to Tangible Transformation
The Codelitt team was pleased to participate in the Re:Connect webinar this past June with a panel describing some foundational concepts in digital transformation in Commercial Real Estate with our presentation entitled “Digital Diagnostics: from Symptom to Solution”
The panel discussion showcases three members of Codelitt’s leadership team speaking about the role of User Experience Research in identifying data driven pain points, the merits of off the shelf, hybrid, and custom solutions, and strategies for converting concepts from the abstract into tangible roadmaps to digital transformation.
Our third section features Chris Lusk, Codelitt’s Director of Partnerships, discussing the process Codelitt employs when partnering with a company that has decided to build a custom solution, with specific emphasis on the importance of building a roadmap toward digital transformation. (transcript below)
Hosted by Unissu, Re:Connect is the world's largest festival of innovation in real estate. Explore 200 sessions led by global thought leaders, all with the mission to inform your innovation and transformation strategies!
Michael: The next section deals with what the process is like when a company is actively seeking a custom solution. So, we’re going to talk to Chris Lusk, Director of Partnerships here at Codelitt, he’s going to give us a breakdown of the steps we would take as far as our lab and build process in a custom dev space, so welcome Chris.
Chris: Thank you Michael. Welcome everyone. So, yes, the first step that we take, it’s a process is what we refer to as a Lab. It’s how Codelitt goes about solving complex issues, it’s how we go about Building a solution. To put a lab into perspective, it's the thinking that occurs before-the-doing. Whereas the steps previously outlined today helped to define if a digital product is needed, a Lab will then define the scope, the effort, the timeline, the budget for building the solution. We internally refer to it as a roadmap for our clients to follow.
Michael: So kind of transitioning from the concept driven to first into drawing the concept into application. So what’s the first step?
Chris: We first need to define what stage of the product life cycle you are in. Are we talking about a brand new idea on the back of a napkin? Then let’s look at possibly an Ideation Lab or a Rapid Prototyping session.
Is it something that’s a little more evolved and you have already taken steps towards defining the solution, or let’s say you have one of those solutions that is only solving 70% of your needs, let’s look at an MVP Lab.
Maybe it’s an existing product in the MVP stage so we need to figure out Scalability and growth.
Or perhaps it’s a mature product that is missing the mark due to UX issues or an old technology framework so we can look at doing labs around a UX or Tech Stack.
But no matter really where we start, the outcome of any Lab is to define what is the focus and tell you how do we get to the next step, how do we solve those very specific problems that you’ve already defined.
Michael: Well since we’re here at Unissu, let’s talk a little bit more about CRE and how that relates to a lab. Can you describe a typical scenario where you would use a lab in the commercial real estate/Proptech space?
Chris: Yeah and we run these quite often, I feel like we’re the CRE pros, but thats just me being biased. The most common thing we see in the CRE space are companies who have multiple off-the-shelf products, right combined with something that may be custom, large or small. But they usually have a dozen or more subscriptions to various data sources, and the end users are typically brokers.
Over the years they have layered in various digital products to solve one or two very specific problems, usually at the expense of process efficiencies. They spot an issue, they throw something at it. And really they’ve now grown to a point where they need to consolidate these environments. They’ve got to re-streamline if you will the processes again. They’ve got to start using their tech stack as a sales tool to close potentially more deals, retain more customers, and retain more brokers.
This all typically leads to an MVP Lab, again it could be any sort of lab depending on where they’re at, but typically these are MVP labs where we give them a roadmap of exactly how do we solve 1 or 2 of those biggest headaches. Is it taking five or six environments and converting them into one, is it client retention, is it a revenue issue? That’s typically what we see in this space.
Michael: Well lets run a little bit with that one, we have a handful of different kinds of labs that we offer but, lets run with the MVP lab, take us down that path.
Chris: So the first step is a kickoff meeting, we take members of our senior management and stakeholders from the client and we dig into every aspect of your environment. Pre-Covid we would meet in person for a full day kickoff. Post-Covid, we hold these over Zoom, usually 1 or 2, 4 hour meetings. But I’m looking at the attendee list now, if anyone out there is from Fiji who would like us to attend one. We will gladly come visit you!
Michael: I mean like, anywhere, anywhere is fine. Vincent - we can expense Fiji right?
Chris: We’ve got the right person on the call to expense that right Vincent?
Vincent: We’ll talk about that later.
Chris: Alright cool, cool. But yeah, the purpose of an MVP Lab is to understand things like:
What do your digital products look like today?
What limitations are you facing within this specific environment that you’ve built?
What are the top 1 or 2 issues that need to be addressed in order to increase efficiencies, increase the productivity, increase revenues, retain clients, retain brokers, etc?
And sure, a custom built solution could solve all of these problems, but back to what Vincent was saying where do you start?
That’s the purpose of an MVP Lab. It's important to view it as the minimum solution that will either generate revenue, cut those costs, increase the productivity, etc. But something that will impact the bottom line as fast as possible. As Vincent said, cost is the number one thing a company looks at.
Michael: I mean, unless you have a blank check right?
Chris: If anyone out there has a blank check, especially if you have a blank check and are sitting in Fiji, call me, my number is… But I mean seriously, even with a blank check, the journey to building a custom solution should start with some sort of planning and preparation session, and that is exactly what a Lab is.
But those planning sessions are a lot more effective when you have an unbiased party peeking in. People who can call the baby ugly and really get to the root of what you are trying to solve. It’s user experience needs versus stakeholder wants, which is probably why Vicky is smiling off camera right now.
Michael: Sorry I had never heard that expression before, so kind of continuing down the line with cost, you mentioned that typically there is going to a combination of a dozen or so existing off the shelf solutions, maybe some level of custom development integrated into the CRE space, or rather into the companies technology space. From a cost perspective, how do existing products fit into the strategy of an MVP lab?
Chris: Well I think that you have to step back and no matter who you are working with, whether it’s Codelitt, another vendor, it could be your internal team - the mentality needs to be, “let’s not reinvent the wheel.” Again even if you have a blank check. An MVP Lab will help us better understand how much we can accomplish inside of your current environment. Back to cost being a factor. How much of your tech stack can be tweaked, within reason, to solve those 1 or 2 major issues?
For example:
- How flexible are the API’s within your current solution, or those current environments?
- Can we take your current custom or off-the-shelf solution and expand its capabilities with a more comprehensive API infrastructure?
- Could this MVP be a machine layer, something with no user interface, that sits somewhere in the environment to automate repetitive tasks, to send data to other systems, automate reports, things like?
- Could a simple tweak in design, or the customer onboarding process, or the user experience solve the identified problems?
- And when a Build does take place, what are the other systems that it could potentially replace; how much money can we save building 1 system that replaces 3?
And again, I know this phrase gets overused and distorted so maybe we can edit it out later. But that’s really the difference between a partner and a vendor. A vendor is happy to take your money and build what you tell them to, without questioning the practicality, the financial impact. While a Partner asks, “if this were our problem, with the resources or limitations that we have; We have real world limitations as well. How would we solve this problem? How would we build this solution?”
And really we do that with labs, that’s kind of our answer to that question. We have the same constraints as everyone else, so we take those questions very seriously for sure.
Michael: So if the lab is the response to that need, what is the final outcome like?
Chris: So after we do a kickoff, this is really where the magic happens. It typically takes about a week or so. You have a dedicated project manager who brings the UXR and Development contacts together to define what the MVP should look like.
In order to do that we need to know the grand scheme of things. In many cases we will also build “what would this look like to solve all the problems?” That’s the fun part, everyone likes to talk about solving all the problems. Where the real work happens is, if we know you as a client, we know what your cost constraints are, we know what your time constraints are, we will bring that team together to start really defining what an MVP should look like based on the challenges. they’ll start mapping out the project scope, the budget, the timelines.
Depending on the size of the project, like I said it’s typically about a week to define and arrange this. There is constant back and forth. It’s not like we have a four hour meeting and hit you back up a week later. We try to be in touch with your team as much as possible. Because we want the plan that we present to you to be accurate, we know that typically people come to us because there are time constraints. And we don’t have meetings to just waste back and forth, so we want them to be accurate and we want the presentation meeting of course to be as concise as possible.
Michael: Okay, so now that we’ve uncovered all the challenges, and we’ve got this kind of transparency, and consistent communication going on. The roadmap has been laid out? Is there a presentation?
Chris: Yeah so, really once we take a week or so, however long it takes to really build out that MVP, now of course we’ve got to present it to you, and hopefully we’ve hit it. This is typically an hour or so, we lay out everything we uncovered again just reiterating that we’ve heard everything that the client needs and then we present to them essentially the path forward.
It’ll tell them for the MVP Lab what steps it is going to take to build the solution. So we’ll define the scope and deliverables, the timelines, the budgets. The goal, of course, is to be as modular as possible, to give clients enough flexibility to craft an even tighter plan.
It’s why we call it a roadmap. Because it’s a plan that a company can use, and some vendors may not tell you this, but we build these plans so that you have something tangible that you can then shop, to be very honest. You could hire Codelitt to build the entire solution, you could pick and choose components from that MVP roadmap that we’ve put together, you can build half, we can build half with some staff augmentation or project management or UX review. Again It can be used to shop another to other dev or UX shops to compare costs and timelines, or it’s something that you can use to bring it in-house, stress test, look and see if your team internally could build this roadmap that we’ve laid out.
Again labs are just a really good way for a company, whether you’ve built or not, they’re a really good planning session and it's something that you can then use to decide do we want to build this ourselves, do we want to hire somebody. We try to give you as much flexibility and as much knowledge as possible
Michael: So from here, really the only thing next to do is maybe shop it around, and hopefully build the solution?
Chris: Oh yeah just build it, that’s the easy part, you just send us the blank checks and build it.
Michael: I think that might be a topic for another webinar.