We put our customers to work at the 2018 FreeBalance International Steering Committee in Miami last month. The governance workshops leveraged agile development techniques adapted to the government context. FreeBalance uses a unique customer-centric approach to our product and services roadmap. (Yes, we provide advisory, implementation, and sustainability services.)
Enterprise Software vendor roadmap practices are similar among vendors. Product Managers develop roadmaps based on feedback from systems integration partners and customer feature requests. The primary customer connection to software manufacturers is through system integration partners. These systems integration firms generate revenue through code customization. Incentives are not necessarily aligned to customers. Manufacturers are rarely involved directly with implementations.
Requests for product enhancements come to software manufacturers through the customer support channel. Manufacturers are often disconnected from customers. Product Managers are expected to make up for this lack of feedback. Accepted product management practices include managing and triangulating feature requests. Product roadmaps become “feature lotteries”. The results often disappoint every vertical market equally.
![Project Roadmap Management: Enterprise Resource Planning Approach]()
Context and Product Roadmaps
Understanding context is the most difficult challenge for Product Managers. Product Managers often have to guess why customers are asking for specific features. What problem will this feature solve? Is it a shared problem and ought to be part of the product? Roadmap management often relies on Product Manager experience and opinion. Product Managers often have to abstract multiple requests to identify patterns.
This comes in wake of ‘brilliant’ ideas from executives, or push-back from development teams who have engineering preferences. (There’s a saying that Product Managers are like mini-CEOs – that’s highly misleading because Product Managers do not have ‘hire and fire’ privileges.)
Product Managers often have to balance feature needs with technology ideas. Emerging technology is more interesting, but Product Managers are often faced with creating leading-edge solutions in search of problems.
Great effort is taken to map out product futures. Visio diagrams, PowerPoint presentations proliferate. Software manufacturers build out complex roadmaps across many years. This seems strange given the pace of technology change. We’ve seen numerous cases where manufacturers have been unable to predict future needs. Many new products, and new versions of existing Enterprise Software products, have received underwhelming customer response.
What happens after large Enterprise Software firms enter new markets with optimistic roadmaps? More often that not, these firms have to acquire agile firms.
The traditional Enterprise Software roadmap approach is broken.
Customer-Centric Unbroken Roadmap Approach
FreeBalance has been using a roadmap voting approach at FISC conferences since 2007. This approach is facilitated by our government-only focus. We don’t sell to any other “vertical market”. It is also facilitated by our involvement in all implementations. We get direct input from our implementation services staff. And, we get indirect input from systems integration partners, and through direct feature requests.
FISC provides the context behind roadmap items. Our roadmap is adjusted every year at FISC through a voting process. As I wrote back in 2014:
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.
These leaves us in an interesting situation because Enterprise Software vendors have conditioned buyers into expecting vendor-focused roadmaps, rather than customer-focused
feedback loops. Prospective customers want to see our 5 year or 10 year roadmap. We could produce a document that meets this objective, but it’s an exercise in futility. Our product and services roadmap changes yearly. Technology cycles have compressed. As shown above, we focus on government and the Public Financial Management Component Map. This is the core vision behind the FreeBalance Accountability Suite. Our roadmap is bounded by this component map. Effectively, our roadmap includes anything in the PFM Component Map.
Our roadmap consists of items expected for 1 year, 2 year and 2+years. These change every year. That’s why we leverage agile processes and integrate product development with implementations services in our A-i3+qM TM methodology.
FreeBalance Roadmap Trends
This was my 12th year collecting feedback from our product roadmap. It’s been a fascinating journey uncovering gain aspirations and governance pain points. Some of the trends I’ve witnessed include:
- Addition of a services roadmap because of gaps from traditional service providers and donor partners
- Increased focus on non-functional requirements, particularly for improved maintainability, lower operating costs, and improved integration with non-FreeBalance subsystems
- Increased technology literacy and capacity
- Uncovering usability solutions that reduces training footprints
The 2018 roadmap had products and services with emerging technologies like “blockchain”, machine learning, low-code development, and smart government.
We spent more time this year articulating why product or service items were beneficial than previous years. These benefit statements were aligned with public finance, civil service and transparency requirements that many government share. I am happy to say that the top item on the roadmap came from FISC customer brainstorming. (One of my ideas came second with 98% of votes of the top item).
Agile Extends Product Roadmaps Organically
We rewrote our software with a component-level Service-Oriented Architecture (SOA). This enabled us to compose new applications based on reusable business components, that we call “government entities” in a unified design. This reuse facilitates our product roadmap.
This approach also enables custom development, including the development of unique government applications. These come from unique reform laws. But, almost all FreeBalance implementations are subject to some unique legislation. Our approach to this situation differs from market norms.
Systems integration firms customize code for specific needs. That’s the accepted practice. As described in a post last week, this leaves customers “high and dry” with orphan code and technical debt.
FreeBalance is always part of government implementation contracts. Customization to unique needs are contractual requirements.
The FreeBalance customizes code for customers in most situations. FreeBalance has an Integrated Development Environment (IDE) built on Eclipse. Partners and customers can be trained. Few customers have done so because of the elegance of the A-i3+qM TM methodology for custom development.
- FreeBalance on-site services staff build storyboards and use cases interactively with customers
- FreeBalance product management staff validates this input using technology knowledge, and identifies additional how government entities can be extended for other PFM Component Map requirements
- The validated storyboards and use cases are approved by customers
- FreeBalance product management staff develop specifications
- FreeBalance product development validates the specifications before developing code
- FreeBalance on-site services staff adds to the quality assurance to ensure that the result meets country needs
- Client User Acceptance Testing validates using the code in production (or demonstrates a need to adapt specifications)
The diagram above suggests that the process comes to an end with approval from the Client UAT. That’s a bit misleading because it only ends the process of getting software into production….