We recently wrapped up one of the biggest product pushes in e-PlanSoft’s history, putting the finishing touches on our new Plan Review Experience while introducing a new generation of AI capabilities.
Along the way, we’ve been asked a simple question by customers, partners, and even prospective customers:
"How do you decide what to build next?"
The short answer is that we try not to think in features. We try to think in jobs.
That might sound like a subtle distinction, but the difference between those two terms is an important philosophical building block of how we build software here at e-PlanSoft.
Over the past year, our product team studied more than one million in-product interactions, spent hundreds of hours with plan reviewers, and conducted conversations with agencies across the country. The goal wasn’t simply to collect feedback. It was to better understand the work our customers are trying to accomplish every day.
Customer Research Is Only Half the Story
Most software companies collect customer feedback. The harder part is knowing what to do with it. If ten customers ask for ten different features, do you build all ten? Probably not.
The more useful approach is to look for patterns in what you’re hearing and identify the underlying problems that keep surfacing across different requests. That turns a long list of feature ideas into a smaller set of customer problems you can actually prioritize.
It helps to have a framework for doing that.
That’s where a product development framework called Jobs to Be Done (JTBD) has been incredibly helpful for us.
Jobs to Be Done theory presupposes that while people buy products, what they're really doing is hiring those products to do a job for them. That sounds a little philosophical, so here's a real-world example to illustrate the point. Think about buying a drill at Home Depot. You don't really want a drill. What you want is the job that the drill does, done. You want a hole in the wall so you can hang a picture. The drill is simply the thing you've hired to get that job done.
Still with me? That same idea applies directly to our world of software. A company doesn't buy a CRM because it wants a database with a bunch of fields in it. It hires a CRM to organize what it knows about its customers and prospects and help its sales team turn that information into revenue.
A finance team doesn't buy accounting software because it wants to spend more time in accounting software. It hires it to keep accurate books, understand where the money is going, and close the month without losing its mind. The features matter, of course. But they're a means to an end.
Plan review software is no different. Plan reviewers aren't looking for more buttons, tools, or features. They're trying to review plans accurately, communicate clearly with applicants, and move good projects through the process faster.
That's the job they're hiring us to help them do.
Once you start looking at software through that lens, customer conversations become much more valuable. Instead of hearing one-off lists of feature requests and product ideas, you begin listening for recurring patterns about the work people are trying to accomplish. You begin to contextualize what you're hearing from customers in terms of the jobs they're trying to get done, the relative importance of those jobs, and what is getting in the way of those jobs being finished.
If you’d like to learn more about the framework, the Christensen Institute has a great introduction to Jobs to Be Done available here. It’s a short read and a fascinating way to think about why people adopt products (and why high-performing product teams focus on customer outcomes instead of feature lists).
What We Learned
One of the biggest lessons from this project was that customers don’t always describe their work the same way they actually perform it.
Watching real plan reviewers work often revealed frequent tasks that barely came up during interviews. Other times, we found small frustrations that seemed insignificant on their own but repeated dozens of times throughout the day.
Those observations led to a few critical decisions about the next version of our products. In several cases, we simplified workflows instead of adding new ones. We removed unnecessary steps. We reorganized common tasks around how reviewers actually work instead of some idealized vision of how we thought they should work.
That same customer-centric philosophy guided our approach to AI.
Rather than asking, "Where should we build AI?" we started asking, “Where can AI help reviewers complete an important job faster while leaving the final decision in their hands?”
That thinking naturally led us toward practical applications like helping agencies review incoming submittals, locate information within drawing sets more quickly, generate better starting points for review comments, and compare revisions more efficiently. Here's a clip from our first AI webinar where we unpack how JTBD theory guides our customer research and led us to the prioritized jobs you're starting to see in our product.
How JTBD Thinking Shaped Our Summer Webinar Series
If you attended any of our Summer Webinar Series, you probably noticed that we tried to balance the time we spent talking about what we built with an explanation of why we built it.
We wanted to show the customer feedback and observations behind the product decisions: what reviewers told us was getting in their way, what we saw when we watched them work, and how those insights influenced both the features we prioritized and the way we designed them.
If you missed the live presentations, the recordings are available here:
Our view at e-PlanSoft is that customer research is something you always need to be doing. It’s the part of product development that is never really finished.
Every customer conversation, support ticket, product interaction, and site visit teaches us something new about the work our customers are trying to accomplish. Sometimes it confirms something we already believed. Sometimes it shows us something unexpected.
Our job is to listen carefully, identify the patterns underneath individual feature requests, understand which problems matter most, and build software that helps local government teams do their work more effectively.
That’s the thinking behind our newest releases. More importantly, it’s how we intend to keep deciding what to build next.
Want to see what we're building inside our core plan review experience or with AI plan review? Get in touch with us today.
e-PlanSoft™ Team: Aug 11, 2026, 7:28:37 AM
e-PlanSoft™ Team