Successful product overhauls don’t happen overnight.
In the case of HealthJoy, the window was two years. That’s how much time the healthtech company invested in developing HealthJoy 2.0, which the River North-based org debuted in April of this year.
The multi-year effort wasn’t born out of dissatisfaction with its predecessor, HealthJoy 1.0. Rather, it was part of a continuing effort by the company — which garnered $30 million in Series C funding early this year — to lay a technical foundation that serves their mission of making it easier to be healthy.
“Guiding members to affordable and high-quality healthcare was really central to this entire 2.0 experience,” Sales Manager Kenisha Baxter said.
According to VP of Product Neehar Garg, the extensive project, which sought to improve key areas like navigation and chat capabilities of the platform, required simplifying the codebase, rewriting the front end in React and leveraging gRPC for the chat’s client-server communication, among other efforts.
“HealthJoy 1.0 needed to be more well-organized to handle the overall expansion of benefits we saw in the employer space,” Garg said. “We knew we had to move ahead to stay nimble in the future. We knew we had to build a stronger platform for future expansion of features and integrations.”
We knew we had to build a stronger platform for future expansion of features and integrations.”
Based on feedback teammates said they’ve received, the long-term effort for 2.0 appears to have paid off.
“From an implementation perspective, we’ve seen a lot of excitement around the app from our clients,” Implementation Manager Katrina Slavik said.
Below, Garg, Slavik and Baxter unpacked the product, sales and customer-facing efforts behind bringing the project to fruition – and the values that fueled its successful completion.
How did the company’s mission impact the development of HealthJoy 2.0?
Baxter: Our goal and mission are to simplify the benefits experience, and to guide our members to affordable and high-quality healthcare. What brought on enhancements for the second version is, how do we continue to grow and expand what we’re doing? How do we continue to create and evolve a space that’s so complicated as healthcare?
Garg: The nice thing about a mission that is straightforward is that you can get to pretty straightforward conclusions. It gave us a pretty straightforward path to a lot of the design and product decisions around the expansion of benefits in the employer space for HealthJoy 2.0, which is where our business was going.
Slavik: We’ve had great feedback from clients about how it is driving a seamless experience for members to be able to navigate and view all of their benefits, which satisfies our mission of simplifying the benefits experience.
When launching a product, it’s so important to be really crystal clear on the messaging.”
From a technological perspective, how did HealthJoy 2.0 come together?
Garg: We broke down the portions of our code and our processes that we didn’t feel would scale as well as we wanted to. I think 97 percent of our code for our new mobile apps was written using Swift for iOS and Kotlin for Android. It helped us avoid most of the bugs related to memory management type overflows. Other things were simple little programming mistakes because those languages are designed for safety. It eliminated a lot of boilerplate code, making it easier to maintain.
We also used gRPC as the main technology for our chat for client-server communication. It helped us define a strict protocol using Google Protocol Buffers (protobuf) for our chat data model — which we then use for cogeneration — and data transfer consistency between the mobile app and the chat back end. That allowed us to basically reduce the amount of data transferred by 30 to 40 percent, compared to our previous implementation.
We also rewrote all the front end to React, which helps us iterate faster on changes for our benefit wallets and our ticket cards. Also, we transitioned our web-based telemedicine and take to native code. That brought audio and video calls integrated into the system, so they feel a bit more familiar and intuitive and are harder to miss.
Additionally, we transitioned to using an encrypted JSON Web Token (JWT) for request authorizations between our mobile apps front end, back end and across all microservices — which is just good data hygiene — and also started providing two-factor authentication as an option for securing access to our clients’ accounts.
How HealthJoy’s mission empowers teammates:
- Garg: “We’re trying to enable more access to high-quality and affordable options for our customers and for our members. That mission resonates with me a great deal.”
- Baxter: “We’re going after creating a more streamlined employee and member experience so that we’re able to meet individuals where they are.”
- Slavik: “What really brought me here is the true focus on value for our clients and our members.”
What challenges arose in the process?
Garg: The transition of architecture out of monoliths was a huge technical challenge that was pretty hard to pull off without breaking things in the current experience while we were doing it. We made thousands of improvements to logic over the years, so a lot of duplicated complex logic accrued in our code across our platforms. We had to centralize all that logic in the cloud, which lets us reduce file size, improves performance and decreases battery life drain. It also lets us do more parallel development across our engineering org as it grows.
That transition process is very hard because it basically requires carving out portions of the monolith of the monolithic aspects of our architecture into services as we go and have them immediately keep working. The baseline functionality that they were supporting was still often available in the 1.0 version of the app even while we were doing it.
What are your key takeaways on how to do an undertaking like this successfully?
Baxter: Be crystal clear on the messaging around the product. Connecting the next phase of the product you’re releasing to the market need is crucial. It’s easy to assume that individuals you’re selling to will understand why something was done. In sales, it’s always something I’m thinking about: How am I refining my message? How am I connecting the dots?
Slavik: Understand your clients and your target audience and make sure you’re adapting your product to it. The rollout of app 2.0 was really important to drive that value for our customers with a really seamless easy in-app experience.
Garg: Start from your mission and think about where you’re going beforehand. We started working on 2.0 when our app was working fairly well. But we were able to look forward and know what the future of our app experience was going to be like, and use that as a guidepost to start investing in that work fairly early on.
