3 Takeaways on Product Management in the Singapore Government — from GovTech’s first PM Unconference
Last week, some product managers (PMs) from GovTech Singapore got together for the first ground-up Unconference for GovTech PMs. Starting small and cosy, a good 30 of us attended, many of us meeting one another for the first time.
This get-together was incredibly helpful and long overdue, as the challenges that PMs face for tech products in the public sector, and in Singapore, are unique. The answers we need can’t be found online — mostly from anecdotal sharings. I ended the session with a lot of my pressing questions answered, feeling relieved that my pains were shared, and heartened by how generous and supportive this GovTech PM community is. I left pretty inspired and motivated that I decided to pen down some of these takeaways, and why not share them on Medium?
Challenges of Product Management in the Singapore Government
The Government Technology Agency of Singapore, better known as GovTech, essentially leads the digital transformation and development efforts of the public sector, for citizens and businesses (Source: GovTech LinkedIn).
This means that what we strive for extends beyond profit maximisation as is with most businesses. We have a variety of stakeholders, we need to cater for 100% of Singapore and not just willing users, we need to work towards what’s “good” for society, we need to charge to recover costs but not too much, etc. Many of these considerations are at odds with one another so a delicate balance has to be sought.
With this context, here are 3 discussion points raised during this Unconference that left an impression on me. These were brought up at different parts of the sessions and they are somehow still on my mind.
1. Products displace problems
“What problem is your product trying to solve?” is a common question asked of startups to define the scope of their solution and value-add. As a fellow GovTech PM (Ben Goh) pointed out, a product can solve a problem, but it can also create other problems.
For instance, Facebook and other social media platforms connect people and communities. In turn, these platforms became extremely addictive and a source of fake news, among other fallouts. How accountable the founders of these platforms should be held for the undesirable outcomes from widespread usage of the platforms surfaced again at the recent U.S. Senate hearing.
In striving to solve a problem, another problem may be created. I noticed that in my product, AIBots, which is a platform for agencies to create chatbots powered by ChatGPT with their internal knowledge base through Retrieval-augmented Generation (RAG). As many public officers flock to leverage the benefits that LLMs can bring today, augmented even further with contextual knowledge added, the risk of misuse increases. While a product team in the private sector would normally strive to maximise the number of users and use cases, a team like ours serving the public sector would prioritise minimising the risk of AI Bots and actually deny use cases surfaced by enthusiastic users. Sure, a RAG Chatbot answering public queries could significantly ease the load of helpdesks, but the rate of inaccurate responses by ChatGPT is high enough that we would likely not want to risk any member of the public receiving wrong information from an official source.
With every product (or solutions, too) developed, other problems are created. Perhaps these other problems are less important, or less urgent. Our teams may not be able to address these problems at once or mitigate the fallout, but we should at least be conscious of the secondary issues arising from our products and deal with them one day.
2. Establishing a Pricing Model for Government Products
Unlike the private sector, GovTech product teams do not have the pressure to maximise profits. This may seem like a relief, but we are expected to recover the costs of development and operations when they are used by agencies or businesses. The underlying principle is that the costs our users save from using our product should be higher than the price they will pay. This indicates a value-add from our product which can justify the development and operating costs, including manpower costs (the most expensive item).
On the flip side, we are expected to not overcharge for our products since, as a government organisation, we do not seek to profit. We then have to identify a balance point for a pricing model that can recover our fixed and variable costs, but not by too much, based on an estimated demand.
To add another layer of complication, there is a wide variation in the mode of purchase across teams. For a product like AIBots, usage can be paid for in smaller units (e.g. one AI Bot, 10k queries). However, given that Agencies would include their expenses in their budget plans for the financial year, a bulk purchase of e.g. 100 AI Bots and 1 million queries may make more sense.
Other PMs shared their experiences in establishing pricing models for their products and while I learned a lot and now have a better idea on how to approach this step, I am well aware that this would not be straightforward.
From the outside, it may seem that however the money flows within the government, this goes from one pocket to another, and the source still comes from tax revenue. These financial processes within the government serve to ensure accountability, but can there be a simpler way? (I would love to hear suggestions from this, perhaps even from public officers in other countries!)
3. Knowing when it’s time to close (and how to do so)
When a business doesn’t earn enough, they lay off staff, they apply for bankruptcy, they shut it down. In the government, some products may not be cost-recovered immediately, but it is essential that we build them as they may not even be provided in the free market.
How do we then determine whether a government product should or should not continue? What happens to those teams who were working on the product, given that layoffs do not happen in the government? What would the loyal, existing users do? Does this mean the team has failed?
This was another topic discussed extensively, as these questions become more pertinent as our organisation and our products mature. New technologies develop, new solutions are created, and the landscape in the tech industry evolves quickly. The need to sunset products may not be in the control of the team. When a better alternative is clear, the best way forward could be to end the product’s lifecycle, as painful as it may be.
In your business and perhaps your life, the tomorrow that you desire and envision may never come to pass if you do not end some things you are doing today.
— Dr. Henry Cloud, Necessary Endings
The book Necessary Endings by Dr. Henry Cloud was recommended by another fellow PM, Adan Vielma, which explains the benefits of letting go and describes practical steps on how to best do so.
I am immensely glad that I am not in such a position now because it is not an easy task, especially emotionally. When I do find myself responsible for such a decision, I hope that the organisation culture respects the team for doing so and does not see it as a direct result of the failure of individuals.
Clearly, there aren’t simple concluding answers to these three discussion points. There are many considerations here unique to government products, where recommendations and solutions would also be unique to our environment. I can’t seem to find much content out there addressing these issues in such a context of technology products in the public sector, and I absolutely welcome suggestions and comments on these topics.
