Podcast Episode: Today’s Web Apps, Pt. 2

This week’s episode is the second in a three-part series about custom web applications for today. Justin Bantuelle, Chief Operating Officer & Web Technology Director at Health Connective, breaks down how to choose what you want your custom application to do. In this episode, you’ll learn how to scope the application, the dangers of trying to fit everything into Version 1.0, and the complexities that are introduced when you try to develop an application on the cheap and then add to it later. (Hint: it costs more in the long run.)

Engage With Us

How to listen: shows.pippa.io/paradigm-shift-of-healthcare/howto

Follow on Twitter: https://twitter.com/hlthconnective

Full Transcript

Announcer: It’s time to think differently about healthcare, but how do we keep up? The days of yesterday’s medicine are long gone and we’re left trying to figure out where to go from here. With all the talk about politics and technology, it can be easy to forget that healthcare is still all about humans. And many of those humans have unbelievable stories to tell. Here, we leave the policy debates to the other guys and focus instead on the people and ideas that are changing the way we address our health. It’s time to navigate the new landscape of healthcare together and hear some amazing stories along the way. Ready for a breath of fresh air? It’s time for your paradigm shift.

Michael: Welcome to the “Paradigm Shift of Healthcare,” and thank you for listening. I’m Michael Roberts here today with my co-hosts, Scott Zeitzer and Jared Johnson. Today’s episode is the second and a three-part series about custom web applications. We’re going to be breaking it down into three key questions we just recorded last week, when does it make sense to develop a custom application? This week we’re going to be talking about what should the application do? And in a future episode, we’ll be talking about how it should be developed. We’re back today with Justin Bantuelle. He’s our chief operating officer and web technology director here at Health Connective. Justin, thank you once again for joining us on the show today.

Justin: Yeah. Glad to be back.

Michael: Awesome. Awesome. So, listen, last time we got pretty heavy into all of the things that a company should think about when they’re ready to start building out applications. You had a really great answer about applications are there to just meet these business needs. You know, obviously, they’re complex and they do a whole bunch of things, but the core of it is that they meet business needs. And so, one of the things I wanted to kind of dig into before we get into some of today’s show is kind of talking through the ways that we’ve helped businesses meet those needs. You know, in the last episode, you spoke some about we worked with a healthcare company around an HR tool, which was kind of difficult and was kind of a lot of unexpected headache on their part. You know, but we’ve also helped with companies developing things like ordering systems so that if a hospital needs to put in orders for different types of parts, they can get it directly from the company. I know that we’re even doing some very complex work right now around grabbing data from even surgical robots, from some of those kinds of tools that are out there and helping display that in a useful way for a variety of teams. You know, like, are there other things that you can think of kind of off the top of your head around ways that we’ve helped specifically within the healthcare space?

Justin: I think you touched on a lot of the really large ways that we’ve interfaced. A lot of times there are smaller business process needs. People just need to capture feedback from someone internally or externally and they need to be able to review that information. A lot of web apps is just processing and presenting data, and it tends to be the specific ways that you need to achieve that, the specific considerations that they, as an end user, maybe have thought of but don’t know exactly how to accomplish and they just want to hand off, like, “I have this. How can work with it?” And we kind of guide them through that process since we understand that. Working with data from robotics platforms is definitely some of the more significant and challenging areas around it. When you’re replicating something that’s like formally handled with like spreadsheets or paper forms, that tends to be a little more straightforward.

Michael: It should.

Justin: Very important still, and it can save a tremendous amount of time. And then, like you said, ordering, a lot of times creating like catalogs of products and allowing customers to view those easily, search through them. There’s just a lot of needs within the healthcare space. It all generally comes down to data.

Michael: Absolutely. Which is, for some of those like us, like me, in particular, you know, you hear the word data and it’s just this magical ethereal thing that’s out there that somebody has to deal with. You know, you talk about dealing with robotics in particular, and that being a challenge. What is it about that particular aspect that is so difficult to interface with?

Justin: There’s a few different angles on it. One of them is just security. So, these things are highly regulated by the FDA. So, ensuring that you know the ins and outs of how to meet compliance, how to document your process in a way that produces the right paper trails that’s easily presentable when there’s audits and things like that. That’s one facet of it. From a development standpoint, it’s just a lot of data. There is a tremendous amount of information that people care about coming off of these robots. And there’s a lot of different people who want to see that data in different ways. If you’re a physician, you want to know how well you stayed on track with the plan that you made, you want to see how long these procedures were taking, you want to see your average case time, and then you want to drill down into other sorts of specifics around that. So, you really care about how did I do with the procedure that I just ran with this robot? But then, you may have like an engineering team that’s involved with the building of the robot and needs to know, what are we doing next? What is our robot maybe not quite accomplishing that we can refine?

So, you need to slice that data, but you’re looking for potential failure points or areas where, oh, we must not have trained our customers correctly. This is really odd and doesn’t match what we were seeing in our trials, where we had a lot more control. So, they care a lot about a very different component of it. Then you have people who service the robots, because these are very complex machines. There’s a lot of parts that you need to sterilize, ship back, return. So, there’s a whole service component to it that they need to know specific kinds of information that just no one else on the other teams cares about. So, these are just some of the examples of different ways that this data needs to be sliced and visualized and knowing what’s important to certain people, how to surface it in a way that’s digestible for them that really meets their needs for each of these different groups. You can have a single page that everyone can see, but they’re gonna have to wade through information that’s going to be really useless for them. It’s just going to be a bad experience. So, I’d say just the loads of data and understanding how to process it and present it in a meaningful way for such a wide range of use cases.

Michael: It’s interesting, because we’ve had so many different, you know, entrepreneurs that have been on the show and, you know, rolling out a new product, rolling out a new program, and this isn’t the part that everybody talks about, right? It’s like, here are all the different people that need to be involved in that as well. And it’s not just selling it and getting somebody to agree, yeah, this is a good tool, but also, yeah, there’s a whole bunch of people that support you.

Scott: Justin, you bring up that there’s a lot of different people to interface with when it comes to a custom application. I think it’s one of the things that we bring to the table. We’ve definitely got the background to talk to the IT department, the marketing department, the sales department. We have either been in that department, worked with that department, etc, over the years, and it can be a little overwhelming. I think, from my mind, we have seen this a lot where in version 1.0, practically everything you try to throw into it, and that may not be the best approach. Do you agree with that?

Justin: I definitely agree with that. So, it kind of goes back to what I was saying before that viewing something that is this like one-and-done product is not going to serve you well. And with that in mind, the idea of what is the minimum viable product, what gets me off the ground in meeting my immediate need is very reasonable and is kind of essential to success in a lot of these situations. But looking to, what are my nice-to-haves? What do I really need by this phase two, this phase three? Breaking that up and having a realistic timeline and not waiting until everything’s flawless and you have every single feature you want. Like, it makes it cheaper, it spreads the cost out, and it gets you up and running faster. It’s absolutely essential, in my opinion, for any complex web application to be viewed as a series of phase releases for various features and updates.

And there’s a concept that goes along with this in maturity. So, it is that, if you’re still trying to bootstrap yourself, you maybe don’t need a fully mature product. You maybe just need to meet these immediate use cases. But as you mature, as you have revenue tied to that that’s coming in, now it’s much easier to justify the next phase. So, maybe the next phase is a really big step. Maybe you’re ready to use some kind of enterprise solution that you integrate with the product that has a very expensive license, but it’s essential that you have that once you start operating at scale. You don’t need to figure out how to fund that right out the door necessarily.

Scott: No doubt. Yeah. You know, and then as you’re saying, Justin, I can’t tell you how many times you and I have worked with a company where there was this inference that a tremendous amount of gain was going to come from feature A and it actually came from feature B, you know. So, nothing wrong with feature A, it’s working fine and it’s doing what it needs to do, but wow, look what we’re getting out of feature B and what do we need to do. So, not jumping too far down the road and thinking things through in a phased approach has always been a win for us.

Justin: Yeah. It really allows you…that’s a really good point. You can get to be reactive to how it’s taken shape and the ways people are engaging with it. That’s another common pitfall is that, if you think you got it all figured out, you don’t. No one ever does. So, you build what you think people need, and then once it goes into production, once people start using it, you realize there’s all the bad assumptions you made, and there’s nothing wrong with that, that’s how you learn. But if you didn’t plan for that or if you have a very rigid idea of what it needs to do and you’re not responding to the data you’re getting that doesn’t match your expectation, you won’t be positioned well.

Scott: Yeah. You know, and the other part of the too, I brought up these three departments that at many companies can be siloed and always work best when they’re…we all work better when we’re working with each other. So, you have sales, you have marketing, you have say IT. And how many times have we built a system when we’re working just with marketing and then we bring IT in and they have some great suggestions, they know what platforms are working for them, what future, what direction they’re taking with those platforms and tech stacks. And we say, “Hey, that’s great. Glad that we know that.” And then all of a sudden, sales sees this and they start to see it working well and they go, “Wow, this is great. What if…?” And that’s that, again, guys, anybody listening to this, that’s where it’s so exciting actually if you take a phased approach to it, because you’re able to take advantage of that, you know. You’ve got budget, you’ve got buy-in now, and you’re starting to see expectations not only being made, but you’re starting to see other possibilities about what this application can do from a return-on-investment perspective.

Justin: Yeah. I completely agree with that. And on the flip side of it, the more siloed you are, often, the more you miss those opportunities. And that’s something that I think at least for us we’re able to sometimes provide because it’s understandable that any given department has objectives that they’re trying to work towards. And that’s how success has been defined by them, by their bosses. And they may not get that whole picture the same way that we do when we’re building out the app because we’re just trying to meet the requirements that have been articulated. So, it makes us a sort of neutral party as the development of it. So, sometimes we see opportunities that are maybe otherwise left on the table.

---

Michael: Everybody, I always appreciate that you tune in, that you’re listening the show here. I wanted to let you know that we have set up a new newsletter that you can get to at paradigmshift.health. That’s paradigmshift.health. You can go there and the reason that we’ve got this newsletter is that we like to send out a few extra pieces of information with the show. We also have the full transcript for every single episode that we do. And we can let you know that through email, we can let you know also if we have like a good quote card to be able to show for every episode. So, check that out if you’d like, paradigmshift.health. Thanks so much.

---

Jared: Justin, one of those opportunities that I think we’ve all seen quite a bit, and I’m sure you’ve had the opportunity to deal with one way or the other is, when we try to get an application done as cheaply as possible, and then just say, “We’ll add onto it later.” You know, there’s various points where I’ve been involved and we just start laughing when we talk about, you know, version 2.0, or phase 2.0, where we’re like, “We know we’re never going to get there. So, let’s just cram it all into version 1.0.” And obviously, that introduces some complexities. What happens when we try to do it that way, when we try to just do it as cheaply as possible and then just think we’re going to add onto it?

Justin: Yeah, that’s a great question. So, maybe a foundation is a good analogy. Like, I don’t know a tremendous amount about building homes, but I’m reasonably confident that a shoddy foundation means that no matter how quality the things on top of it are, you’re going to have problems that will be endemic throughout the lifetime of the home. And it really comes back to that when you’re trying to get started. So, if you take the cheapest way out upfront, then often, touching back on something I had said before, there’s a good chance it gets thrown away. It probably won’t meet your need, like, once you need to mature past that point. The bad foundation means it’s not usable.

There’s also a concept of technical debt where, even if you do manage to hold on to what you built but you really cheaped out on how you got it built in the first place. Technical debt is the idea that, as the system becomes more complex, as more people work on it, you accrue this form of debt that needs to be paid off. And the more that you neglect it, the more interest accrues on this debt. So, you amass a tremendous amount of debt upfront with a cheaply built product where somebody was cutting corners to make that happen. And it’s going to really bite you in the long-term because it’s going to be brittle, it’s going to fail you, and it’s going to be very, very expensive to get out of that hole that you built for yourself there.

And I think this also goes back to this idea of maturity with the product. Cheap is a relative term. So, maybe cheap means that you don’t pay for every feature you need upfront, but you communicate a plan and you come up with a phased approach where maybe you’re budgeting for the next quarter, the next year, whatever that is. You lay out this roadmap for yourself and say, “I can’t afford everything right now.” And you shouldn’t do that anyway, right? We just talked a bit about how that doesn’t allow you to be reactive to the needs of the product as you start to use it. So, the phased approach allows you to save money upfront. You can be cheap if you want to call it that by not building everything you can imagine upfront, but you should make sure you pay for quality with the thing that you are investing in, because it is a long-term investment.

If you’re doing a custom application, you need that to last you a long time. And a good quality investment upfront really pays dividends in terms of cheaper maintenance, it meets your needs better, it just really holds it. And then planning that phased approach. You have that next step, you’re looking forward, you’re budgeting for that, you’re never caught off guard with those sorts of plans. So, there’s ways to be budget conscientious that are not unwise.

Michael: Justin, if you’re trying to advise somebody on how to think in a phased approach, I know we’ve talked some about the benefits. Maybe you could even talk us through some examples where you’ve been in the planning process with someone or you’ve been, even as we’ve often seen happen, like you’re already within the building process, you’re already several steps down the road, and there’s more of those kinds of what if statements. Wouldn’t it be cool if…? When’s a good time to start thinking about this is a phase two, this is a phase three, like how should companies be thinking about what a minimum viable product looks like compared to like what they would like it to look like in three, four years?

Justin: Yeah. That’s a little bit tough because it’s gonna really change based on their budget and how mature they are as a company at the point that they’re looking to build this, like, have they been moving forward without having this, but they were able to accomplish it in some other way and this just will really transform their ability to get the work done versus, we don’t have a product, we don’t have a business model unless this application exists? Right? That’s a very different conversation. When you get into custom application development, it really is very bespoke. So, it is about working with your developer, I would say. It’s about articulating everything you need, but having good expectations. And I think signaling that to the developer, and if the developer is not responsive to that, then that may be a little bit of a red flag.

But knowing that the customer is ultimately going to know best what the bare minimum is for them to function. And it’s not always about building to the absolute minimum viable product. Maybe you really do know enough that you can build out some of these things. And sometimes it’s like, Oh, maybe I can launch with just this one piece of it because this is the one piece that I need to get in front of customers. But then I think here’s what I plan for how rapidly we’re going to ramp up as we start selling this to customers and I know that my support team can handle this manually before we build out the customer support portal component of it.

So, maybe you can afford to phase it that way, right? Where you know this is a business need, it’s an inescapable business need, but you have a ramp up period where you can afford to push that component off and get yourself up and running faster and start budgeting and seeing where, okay, when I hit this milestone and I’ve got like 20 customers, 100 customers, whatever that is, then that’s the trigger for me to then move into this next phase and build out this portal because now I’ve hit a scale that it’s essential that I run with it. And I had a plan. It’s about having a plan more than anything else. And there’s no one right fit for that.

Michael: I’m going to kind of peel back the curtain a little bit, kind of go off-script here and talk about, you know, this is a process that we’re actually going through right now for some of the work that we do with orthopedic clients, the P3 platform that we have. You know, Scott and I get to be the client a lot of times internally because we come to Justin and we’re like, “Justin, we got a great idea. This platform, it’s going to be fantastic. Everybody’s going to love it.” And we start talking just like that, when we start talking about the idea.

But, you know, we have all these ideas that we can throw into the thing and Justin patiently sits and waits and goes like, “Okay, do you actually know what you want this thing to do or do you just have like a bunch of features that you want to throw at the wall?” And, Justin, I want to go ahead and just recount this experience just a little bit just so that, if you’re on the opposite side of this, if you’re looking to engage someone sort of the steps that you need to walk through before you really just go and say like, “Hey, programmer, I got these things. Can you please do something with this mess?”

Justin: Yeah. I think something, you mentioned a couple of things there that are very useful. So, the advantage of having data-driven decisions is invaluable. When you don’t have any data, everyone’s opinion is equally subjective and that can lead to a lot of friction, and it is ultimately guesswork. Even if you eventually come to a consensus on it, it’s somebody guessing. And that’s not a great position to be in. So, putting yourself in a spot where you can gain data before you start that next phase of investment is very, very wise and very helpful.

Michael: There’s a ton more that we can talk about, everybody around this whole concept of application development. We hope that you’ll tune in next week. We’ve got one more episode where we want to talk about really the how all this stuff happens, how it all comes together. So, thanks so much for listening. Have a great a week.