Back to TopBack to Top

Customers Adapt FreeBalance Product Roadmap


February 8, 2014

The annual FreeBalance International Steering Committee (FISC) conference is the most important milestone on my product calendar. Annual vendor conferences are important in the life of any typical software product manager because it is the time when customers learn about new features, changes and new products. Software companies create a demand for this conference by holding back announcements and creating a sense of excitement. This manipulation is clever but far from customer centric. In fact, it’s all about the vendor.

We sought to change the dynamic from product-centric to customer-centric events in 2007. This meant that much of the ceremony associated with vendor conferences had to change:

  • Company to Customer needs: switch the focus from what the company needs to what customers are concerned about regardless of what the FreeBalance contribution towards solutions might be.
  • Selling to Engagement: switch the business emphasis from selling by staffing the conference with executives and managers rather than salespeople. Engage customers so that we can improve products and services.
  • Dictate to Collaborate: switch the dynamic from dictating what products will be provided when to customers changing product priorities, adapting the roadmap and working together for common objectives.
  • Controlling to forum: switch the communications paradigm from slick and controlled presentations to a forum where customers engage other customers, external speakers and FreeBalance staff to learn what works in Public Financial Management (PFM) reform.

Roadmap Voting

The FreeBalance product team provides an updated roadmap at every FISC event. New modules that have been created in the previous year that were selected for development by FISC are demonstrated. The roadmap that consists of modules for which there are contractual commitments are described. Modules that have not had customer commitment are also described. This second set of roadmap items consists of modules that may be anywhere in the development lifecycle from vision to beta-quality. FISC is able to change the roadmap such that modules that are close to completion are put on hold in favour of other modules.

The pattern of customer needs has changed over the past 8 years. It doesn’t make sense for us to complete modules that may have had value in the past but no longer. Most software companies, in my experience, believe that they have more clever staff and better analysis of technology trends than customers. As a result, product managers set product priorities, rarely customers. Our product managers and business analysts are embedded in the PFM discipline so that we are able to predict upcoming trends. The requisite skill that needs to be developed for product managers in a customer-centric company is to be able to use domain knowledge and customer engagement to hone in on these trends. We leap at the outliers and ask the questions that let us understand the context.

This year was no exception in roadmap voting – one class of Government Resource Planning (GRP) modules that had received moderate votes in past years moved to near the top. This was something fascinating because there had not seemed to be a major demand and the needs seemed to be satisfied by other vendors. It turns out that this GRP domain, like many in government financial management, is under-served by incumbent vendors. The technology is dated and inflexible. And, high cost.

I engaged our global staff through one of the internal social media tools that we use at FreeBalance. This generated a lot of nuanced insight that forms a compelling picture of needs. In particular, the need to reform and update processes – something that is constant and relentless in government. This is one of the critical aspects of making PFM reform sustainable: technology that enables, rather than inhibits, process modernization.

Technologists might wonder how FreeBalance has a sustainable software development model if we are constantly changing the product roadmap. Customers expectations have been set by large enterprise software vendors to expect 3 to 5 year product roadmaps with only minor changes. How can the roadmap change yearly? (Trust me, it changes far more frequently than this because we have some effective customer engagement processes.

Legacy Enterprise Resource Planning (ERP) software requires long roadmap processes. (By “legacy”, I mean the top tier ERP packages from the largest four of five vendors.) The technology problem faced by these vendors differs from that faced by FreeBalance:

  • Government Platform: FreeBalance has developed a technology platform that forms the foundation for the government platform. All applications are built using reusable “business objects” that provides extensibility across the product suite. (We call these “government entities” to eliminate the word “business” as much as possible in our standard marketing material because we do not provide software to the private sector). This approach means that the development of net new applications leverages the entities for rapid development. And, any work accomplished for modules on hold have generated new entities that can be used elsewhere. Legacy ERP is developed on monolithic structures that prevents this reuse. (We often find that we can develop a net-new module faster than it takes to code-customize an off-the-shelf application designed for the private sector.)
  • Unifed: FreeBalance uses the platform as the fundamental metadata system of record for the entire suite. There is no need for complex integration among modules because the modules are already unified. There is no confusion in managing expenditure and revenue modules with core accounting. Budget and commitment controls are respected in every application. (This is somewhat unusual in the market where there are payroll, assets and procurement applications that have little or no idea of commitment controls. This results in non-compliance to government processes and frequently exceeding budgets.) This unified approach means that additional functionality does not provide an increased integration burden on FreeBalance as developer or government customers.
  • Open: Major software vendors attempt to build value through the use of proprietary technology. They seek to provide options in the software stack, particularly in middleware, that are more feature-rich than competitors. They fill product gaps by acquiring smaller firms, which adds to complexity and reduces economies of scale for vendors and customers alike. These vendors support some open standards, but are focused on adding perceived value across their product portfolio. When encountering a new opportunity, these vendors are predisposed to building from scratch or buying another vendor. FreeBalance, on the other hand, has an open system. We’re not in the business of having customers fund unneeded development. We’d rather integrate with open products, often open source (mostly the commercially supported versions of these), to keep costs affordable for customers. This also gives us choices to determine what approach we should take to meet requirements giving us economies of scale.

My sense is that we’ve got an inherently socially responsible approach to this market. We’ve evolved these processes over time and continue to seek better ways of embedded our government customers in our product decisions.

The following two tabs change content below.
Doug Hadden

Doug Hadden

Executive Vice President, Innovation at FreeBalance
Doug is responsible for identifying new global markets, new technologies and trends, and new and enhanced internal processes. Doug leads a cross-functional international team that is responsible for developing product prototypes and innovative go-to-market strategies.

Leave a Reply