This article was featured in the Journal Technologies Insider, a free quarterly publication from Journal Technologies. If you'd like to subscribe to the Insider, you can do so by clicking here.
Kaushik Mehta is the Chief Technology Officer at Journal Technologies, and Anthony Rochon is the Director of Court Implementations.
Q: Every six months, Journal Technologies delivers another eSeries Long-Term Support (LTS) release. Customers see the release notes, but there’s much more happening behind the scenes, isn’t there?
BC: A lot more than most people probably realize. By the time an LTS release reaches our customers, we’ve typically spent months (or years) evaluating ideas, coordinating crossfunctionally, developing features, testing, and preparing for release.
One thing we like to emphasize is that an LTS update isn’t just a collection of new features; it also addresses identified issues, performance, user experience, and technical debt. Decisions are made based on how an update will affect customers in six months, two years, or even five years.
Q: Journal Technologies serves courts, prosecutors, public defenders, and supervision agencies, all with different (and sometimes competing) priorities. How do you balance such diverse needs when planning each update?
BC: That’s probably the biggest challenge our product team faces. Every update must deliver value across four different customer communities, each with their own wants and needs. For example, we may hear that courts need new workflow capabilities, while prosecutors are focused on simplifying complex charging processes. Fortunately, there’s overlap too!
That doesn’t necessarily mean every update includes the same number of enhancements for each justice market. Some cycles are driven by legislation affecting a specific market, while others emphasize foundational improvements that reduce complexity, streamline processes, and improve user efficiency. Our job is to balance priorities so each release addresses the most relevant and urgent needs across all markets, while also committing to the technical work needed to sustain the platform.
Q: No doubt new features or major changes tend to draw the headlines, but how do you think about the overall composition of an LTS update?
BC: Many releases benefit from exciting new capabilities that help customers do new things or work more efficiently. At the same time, it’s important to invest in strengthening foundational code and making existing capabilities better.
Take our recent 2026.05-LTS release: it included some great new additions like the Safety Check extension for eSupervision, which helps ensure the safety of individuals in juvenile detention facilities. But it also included improvements to our user interface, along with key quality-of-life improvements across the platform.
Sometimes the biggest impact comes from things that seem relatively minor. If a system administrator saves five minutes every time they configure a screen, or if an end-user can find and view workflow tasks more easily, those small time savings compound quickly across an organization.
Q: Where does the work actually begin? Is every release driven primarily by customer requests?
BC: Feedback we get from our customers is very influential. We also solicit ideas from our implementation teams, customer engagement, support, and others; and we take time to do our own reflection on where the eSeries platform can be improved.
Additionally, we like to look at broader challenges facing the justice sector and draw ideas from how other industries have addressed similar problems. Our job is to bring all those perspectives together and determine what creates the greatest value for the most customers.
Q: Once those ideas are collected, how do you decide what actually makes it into the next LTS release?
BC: Every release has finite capacity, so we prioritize based on several key questions. First, does the enhancement align with our ongoing product strategy? Second, is this something that benefits nearly all of our customers, or is it addressing a specific need? Third, is there a legislative or compliance deadline?
Beyond that, we consider a plethora of factors: user/agency efficiency, complexity, delivery and administrative effort, security and usability, dependencies, and our ability to release and support the enhancement.
Q: Just how collaborative is the process of preparing for a release? When do people outside of Product get involved?
BC: Almost immediately. During the discovery phase, we may work with professional services, support, our customers, and external partners. During product development, collaboration shifts to five main teams: design, development, quality assurance, documentation, and legal.
As we prepare for release, we work with our implementation teams, support, customer engagement, marketing, and sometimes early-adopter customers. By the time an update reaches customers broadly, nearly every department at Journal Technologies has contributed in some way.
Q: How do you determine whether an LTS release was successful?
BC: We look at customer adoption, feedback, implementation experiences, support trends, and whether the release accomplished what we intended. Did it solve meaningful problems? Did it improve day-to-day work? Did it position the platform well for future innovation?
Those answers don’t come overnight because organizations upgrade on their own timelines, based on operational and change management needs. As a result, adoption and meaningful feedback may come well after a release becomes generally available. Still, we use that feedback to shape future releases as best we can.
Q: What about the things that don’t go into a release? Every update has limited time and resources. How do you decide what to say “no” to?
BC: Product management is really an exercise in navigating competing tensions. End-users naturally want features that help them do their jobs faster and more efficiently. At the same time, system administrators need better configuration tools, upgrade capabilities, and management features. The challenge is finding the right balance.
When we do say no to an idea, it might be because it would compromise required security or compliance standards or move in a direction that doesn’t align with our product vision. However, it’s also quite possible that it’s just a no for now, and that we’ll address it down the line when our platform or development schedule is better suited for it.