Abacus platforms help our customers grow engagement and revenue by delivering customised experiences and offers. Whenever we consider adding to the development roadmap this overall mission is at the forefront of our minds.

    Input to the roadmap process comes from multiple sources – our board that sets the overall strategic direction for the company; the Innovation team whose job is to make sure the platforms deliver commercial success for our customers; our support team who understand how customers use the platforms and the day-to-day issues they face; our developers who are aware of the standards, tools and techniques we need to apply to keep the platforms up-to-date; real-time data we collect on how the platforms are actually used and perform; and, of course, our customers themselves.

    With so many channels contributing, it’s important that the Innovation team can manage the R&D programme both methodically and transparently. This ensures that when Abacus invests in a new function or feature we can be sure that it will benefit as many customers as possible.

    So each and every platform change request or suggestion goes through a detailed assessment process. We use Jira to manage these requests – so always make sure your idea has been raised in this way – it’s the only way to get something into the process.

    The first stage is to identify whether the request qualifies as a change or a bug. Most bugs are identified by the support team, but occasionally the roadmap team will come across a change request that represents a feature or function that’s not working as specified. In these cases the team will assess the urgency of the issue and prioritise the fix – sometimes this might simply involve changing the documentation to reflect the actual behaviour. In other cases, the bug will be assigned to the release process. The timing of a fix will reflect the severity of the issue, the number of clients affected and the availability of practical workarounds.


    An example of the R&D Roadmap Power BI dashboard used for monitoring and evaluation.


    All other roadmap requests are then assessed on a monthly basis according to the following criteria:

    Customer RequirementCustomer Requirement – how much demand is there for this feature or function from existing customers? As a SaaS platform provider, Abacus must ensure that any development offers the widest possible benefit to the overall user base. The more customers who will benefit from the change the higher it will be ranked.

    Market ExpectationMarket Expectation – is this feature or function something that would be reasonably expected as core to a customer engagement platform? The request may be a very good idea but is it best delivered through our platform?

    Competitive Advantage Competitive Advantage – to what extent will this feature of function improve Abacus’ position against competitors or in new markets. Increased market share leads to increased investment opportunities for the platform.

    Support Benefit Support Benefit – to what degree will this feature or function make it easier to support or roll out to our platform? Sometimes small changes can make a big difference and the less time we spend on support the more time we can devote to moving the platform forward. Often the effort required here is in better documentation.

    RevenueRevenue – how much revenue potential is there in the feature or function? Are customers prepared to contribute towards the development itself or for any additional costs involved in implementation? It is important that new features or functions make economic sense for our customers.

    DifficultyDifficulty – how difficult is it likely to be to develop the feature or function.

    ProgressProgress – to what extent has any headway already been made on the development (eg through related functionality)?

    The roadmap team grade each of these criteria on a scale of 0–5. Any request that scores low in every criterion will be rejected for the roadmap at this point and information about the decision will be supplied to the support team or account manager to relay to their customers. The team also take account of related items (strategic clusters).

    We then use an algorithm to plot all assessed requests on an overall roadmap grid which helps us determine the complexity (how difficult) and marketability (how useful) of each roadmap candidate compared with all others.

    As a result of this mapping every item falls into one of six sectors:

    1. Housekeeping – these are requests that are relatively simple to develop and deploy but also deliver relatively small benefits for our customers. This might be a small improvement to the backend UX or a minor change to the frontend design. Because they are of relatively low value to most customers they will be prioritised on an as-and-when basis slotting into available ‘holes’ in the development schedule.
    2. Quick wins – still relatively simple to deliver but release greater benefits for our customers. Once again these will be prioritised on a more ad hoc basis but will generally take priority over housekeeping.
    3. No brainers – these are items that offer relatively high levels of customer benefit for relatively little development effort. There are always fewer items in this category and they are always given a high level of priority.
    4. Custom – these are roadmap requests that are difficult or complex to deliver and offer a relatively low benefit to most customers. This is not to say that the request might not be very important for a specific customer. In these cases, it is unlikely the development would take place without customer funding and, even then, it would depend on whether it could be delivered without any negative impact on other customers. One very effective approach we have taken to delivering such functionality is through custom apps that sit outside the main codebase but can be seamlessly integrated with it.
    5. Must haves – these are difficult to deliver and have relatively moderate levels of demand (although this often increases over time). Such items often represent newly emerging standards or technologies that might have been identified by our team or some clients. Such changes represent our medium-term development priorities. Many changes we made for GDPR started out in this category.
    6. Strategic benefit – these changes are much more difficult or complex to deliver but also offer the maximum potential benefits for the platform and our clients. These items represent the long-term strategic priorities for Abacus. Much of the work we do on segmentation and tribal customisation emerges from this category.

    Although the roadmap grid plays a central role in the assessment and prioritisation process of all change requests we also have to consider the practicalities of resource availability and release planning which are constantly juggled to optimise our output. To oversee this process each month there is a meeting of senior managers from across the business that reviews all on-going items and ratifies the prioritisation.

    By adopting this rigorous approach and by sharing as much information as possible with our clients we believe the Abacus roadmap process ensures that working together we constantly evolve and improve our platform’s ability to maximise engagement and revenue through customised experiences and offers.