A product roadmap is not just a list of upcoming features. It is a strategic plan that aligns the product team and customers toward a shared direction.
A well-designed roadmap does not start with the question “What do we want to add?” but with a more important one “What user problems do we want to solve?”
Using the example of Higson LTS 4.2, I will show how and why it is worth building a roadmap around pain points. Because true innovation begins with understanding users’ challenges and designing solutions that truly matter.
1. From Vision to Direction – Why LTS 4.2 Was Created
Each Long-Term Support (LTS) release in Higson is a strategic milestone. These are the versions our clients install with the expectation that they bring not only innovation but also a reaffirmation of high standards.
For LTS 4.2, we defined a clear vision: “To make Higson more innovative, secure, and enjoyable to use every day.”
A key part of this vision is empowering users to make more informed decisions through enhanced product capabilities.
This statement set the direction for the entire roadmap. Instead of starting with ideas for new features, we began with a question:
“What are the biggest pain points for our users, administrators, and implementation teams today?”
2. Identifying Pain Points – How to Find What Really Hurts
Listening to Customers An analysis of support tickets and implementation feedback revealed recurring themes:
- Analysts needing to use external tools to visualize business processes
- A complex system of roles and permissions
- Long loading times for large files
- Frequent questions about AI capabilities
Team Perspective From developers and QA, we heard about:
- Complicated setup of roles and permissions
- Performance challenges when loading large snapshots
- Requests for clearly defined security best practices
Product Perspective Market analysis showed that today’s clients expect more from a rule engine than just computing power. They look for:
- The ability to integrate ML and AI tools, as well as seamless integration with other systems
- High ergonomics and a user friendly interface for both technical and non technical users
- The highest security standards
- The ability to easily manage rules, empowering non technical users to update business logic without deep programming knowledge
- Advanced features for complex rule management, supporting sophisticated business processes and large-scale rule sets
The result was a clearly defined list of key pain points.
3. From Pain Point to Initiative – How to Build a Map of Change
Each pain point was translated into a strategic goal and a product epic. This step was crucial because instead of saying “let’s add a new feature,” the focus shifted to defining and eliminating the problem that limits the product’s value.
Supporting rule changes and version control is critical to ensure that updates to business rules can be tracked and implemented efficiently. This not only streamlines collaboration but also reduces development time, allowing for faster adaptation to new requirements.
4. Rule Prioritization – Balancing Value and Feasibility
A roadmap is the art of balancing what hurts the most with what can realistically be delivered.
To deliver meaningful product value while taking into account factors such as available time and cost, we used three key measures to guide product decisions and build a prioritization model:
- Impact – the value for the user
- Effort – the cost of implementation
- Strategic fit – the alignment with the overall product strategy
When analyzing a product initiative using the three decision measures, the following formula is applied to determine the priority of each roadmap item:
Priority = (Impact × Strategic Fit) / Effort
Example:
This method helps balance innovation potential with delivery feasibility, ensuring that the roadmap reflects both user value and strategic direction.
Types of Initiative Value
The decision measures used in the roadmap also determine the type of value each initiative delivers.
Quick Wins → high impact, low effort (for example UX improvements) They boost team morale and provide immediate benefits for users.
Strategic Bets → high impact, high effort, strong strategic fit (for example Flows or AI integrations) They require significant resources but strengthen market position.
Foundational Work → medium impact, medium effort, but critical strategic fit (for example Security or Refactors) They safeguard stability, reliability, and long-term trust.
Low Priority / Experimental → low fit or low impact These can be postponed or combined with other initiatives.
A sample roadmap with the defined value types and priority levels for the main initiatives in Higson LTS 4.2 looks as follows:
The final outcome of the roadmap for Higson LTS 4.2 is more than just a list of changes. This release addresses real user problems and elevates Higson to a higher level of product maturity.
5. Conclusions – How to Build a Business Rules Roadmap That Truly Works
1. Start with pain points, not ideas
Understanding what genuinely makes users’ work difficult leads to decisions that deliver real value.
2. Think in terms of value, not features
It is not about what we add. It is about what improves the user experience.
3. Listen to different perspectives
The best roadmaps grow out of conversations between customers, the technical team, and product.
Each group sees a different part of reality – only together do they create a complete picture.
4. Plan with stability in mind
When building innovative features, reliability and performance must stay at the center.
Aligning the roadmap with effective business process management helps ensure long-term reliability and supports efficient, automated workflows.
New capabilities should never compromise security.
5. Document and communicate decisions
Every roadmap item should have a clear reason behind it: “Why are we doing this?”
This reduces randomness and helps communicate the vision to both the team and customers.
Summary
Building a roadmap is not a feature-planning exercise. It is a process of understanding problems.
The Higson rules engine LTS 4.2 release shows that when a roadmap grows from real pain points instead of a “wishlist,” the product grows in value rather than just the number of functions.
As a result:
- Users feel that their voice truly matters
- The team feels ownership and purpose in shaping the product
- The product evolves in a way that is consistent, mature, and at the same time innovative