Product thinking as a path to cheaper and better public software?
Many public software solutions struggle with delays, high costs, and poor user-friendliness. An outdated approach to procurement makes it impossible to apply the methods and approaches that modern software development is based on. The best software development organizations leverage rapid software development cycles to deliver value quickly, limit costs, and ensure delighted users.
To put out tenders for very large and expensive IT projects, public institutions and agencies choose to develop highly detailed, high stake requirements specifications that large IT suppliers can bid on. The requirements specifications are usually produced as desk exercises – without user involvement, with limited understanding of technological possibilities, and typically also without the use of prototypes and user testing. And in the worst case, the requirements have been touched up by one of the large language models, so the requirements specification looks perfectly “professional.” Working from a conceptual, high-stake requirements specification is precisely the opposite of what good software development practice dictates.
The problem is made worse by the fact that suppliers are organized to service this high-stake procurement process. They know that they can bid relatively safely and low on projects, as subsequent changes to the projects can be priced high. Changes, which in the product model are a positive indication that we are testing and delivering software to real users, become a negative, costly practice.
A tender turned upside down – can we learn something from the best?
From a software product perspective, strategic vision, discovery, and best-in-class development practices must all three come together for public software solutions to also apply the experiences from the best private sector software projects. We must ask the following questions:
- How do we create Vision in a public context? How do we create agreement on the target audience, time horizon, and overall approach to the software solution?
- How do we provide sufficient time and resources to discovery work and avoid the requirements specification as we know it from high-stake procurement process?
- How do we organize development so we can get short development cycles, optimize feedback from users, and iteratively use data to improve the solution?
Vision in a public context
The need for radical innovation in a public context is typically less than in the private sector. In principle, software development is therefore less risky in a public context compared to a private one. The challenge for public authorities is typically access to skilled software-savvy strategists who can develop a software product vision that makes sense for the given authority. Nevertheless, it is important that there is agreement within the individual agency up through the political layers on which problems one wants to solve for which software users. Such consensus makes it possible to create a product strategy for the agency in question with a clear focus on the following questions:
a) Which customer and user groups does the solution address?
b) What is the economic model? New revenue, efficiencies, better sustainability?
c) What is the time horizon for the solution? Continuous or time-limited?
d) How should the solution account for dependencies on legislation, specific technical platforms, or existing solutions?
The answers to these questions, combined with domain-specific considerations, must be anchored with decision-makers, from agencies to municipalities and regions to politicians, before we can start discovery work.
Discovery minimizes risk and creates collaboration
Discovery is most often skipped in public development projects. Requirements are generated at the desk rather than through prototypes and customer tests. This is a fundamental error that costs the public sector dearly in both time and money.
Instead of tendering software development based on finished requirements specifications, public organizations should tender discovery work. The public sector can advantageously apply principles from Set-Based Concurrent Engineering (SBCE), which Toyota developed to optimize their product development. SBCE means that instead of choosing one solution early in the process, you work with multiple solution proposals in parallel and gradually eliminate the less attractive options based on learning and data.
Concretely, this could be organized as 3-4 parallel discovery projects where different supplier teams are tasked with, for example:
- Investigating user needs through interviews and workshops
- Testing different technical approaches with small technical prototypes
- Validating assumptions about integration with or refactoring of existing systems
- Testing different user interfaces and workflows
This approach provides several advantages: a) risk minimization – by having multiple solutions in play simultaneously, the risk of ending up with a solution that doesn’t work or doesn’t meet users’ needs is reduced, b) better supplier selection – the exploration phase gives the public institution the opportunity to assess suppliers’ ability for actual problem-solving rather than just their ability to write bids, c) increased learning and innovation – parallel approaches create competition for the best ideas and solutions, and d) stronger partnerships – the exploration phase creates the foundation for a more equal collaboration between the public organization and suppliers, based on shared understanding of the problem and solution direction.
After the exploration phase, the most promising approach can be selected for further development – or elements from multiple approaches can be combined into an even better solution.
Short development cycles in product development
When the exploration phase has identified the right direction and the right development partners, the actual development must be organized with short iterations and constant user feedback. Technically, DevOps and architecture must be in order, but also the approach to product management.
To enable short development cycles, the public sector must also change its financing and contract forms. Instead of basing financing on estimated work based on requirements specifications, the focus should be on the number of product teams roughly required to deliver the overall solution. The work is then organized with clear goals and desired outcomes, whereby product managers can measure whether results are achieved. Focus shifts from requirements to the value of the software being delivered to real users.
A way forward: From projects to products
The fundamental change that the public sector must make is to shift from thinking in projects to thinking in products. A project has a start and an end. A product has a mission and develops continuously to better fulfill this mission.
When the public sector thinks in products, there comes:
- More focus on long-term vision and discovery: Because we know that the large, heavy requirements specification will cost dearly over time, more is invested in understanding the problem and testing solutions early and continuously. We move investments forward in the value chain and spend more money thinking slowly to act quickly.
- Faster and more user-friendly development: Because structures for continuous learning and improvement have been established, systems can evolve in pace with changing needs. Software gets out and lives in users’ hands after weeks rather than years.
- Better sustainability, both economically and technically: Because changes to the software solution are built into the design itself, and development is set up to continuously increase the solution’s value for the user and citizen.
The transition to product thinking requires courage to change established processes and structures. But the payoff is significant: The public sector can gain access to the same advantages that the best private software organizations already reap – faster delivery, lower costs, and delighted users.
The way forward is not theoretical. It is based on well-documented principles from product management and agile development that have already proven their value in practice. Now it’s about having the courage to apply them in a public context.
