Lessons in Product Management from Sense

The Sense product team was recently interviewed by GovInsider (courtesy of Thian Siying, and we made the headlines today! Check out the main article here, which has summarised the key messages that our team wishes to put across to the public service.

In this blog post, I wish to elaborate a little bit more on these key messages, which I hope will be taken seriously by any budding product manager in the public service when developing applications for government agencies. We have partnered so many agencies over the past few months, be it developing Sense or change managing business processes. It would most definitely be a remiss on our part if we did not leave behind a legacy of experience for our fellow tech sector colleagues.

For those who are still pursuing meaningful change in the public service, be it tech or otherwise, we hope articles like this will be a small beacon to keep your eyes on the prize of innovation.

-- Yong Kiat

Product management is not just finding a good use case and the successful delivery of a good working product. It's about understanding your market well enough, and tuning your product continuously to the market.

When I first took on the product manager role in January this year, I had assumed that one of my key responsibilities was to just find a good use case. Find a good product-market fit! After all, that's what they teach you in all basic product management courses - start with a good problem statement that everyone's itching to solve, and the business will naturally come.

I also thought it was about just building a good product. Build it and they will come! Surely if there's a product that meets user needs, and I build it, we'll naturally get our business going? What other secret sauces of success would we possibly require, other than the product itself?

I quickly discovered that having a good piece of work doesn't necessarily speak for itself. TransformGovSG took only 1 month to develop a good working version of Sense, but we were nowhere near getting adoption. No one was flocking towards us to use our product.

What did we do wrong? We found a good use case, we built a good product, and we were also government-building-for-government. Why weren't people coming?

Well, we did tonnes wrong. And we would do things differently a thousand times over, if we were called to the same stage again.

If you want to scale, you should never meet all your customer's needs. But if you are talking about first adoption in a niche, your first customer is king.

One of the golden rules in product management is to figure out your unique selling point, rather than pander to all the requirements put forth by your customer base. The rationale is simple: you don't want to spend too much effort sustaining demand, otherwise it's impossible to scale quickly and expand your product lines.

Many entrepreneuers subscribe to this rule - in fact Daniel Priestley himself advocates the need to "position your products and services as unique and valuable in the marketplace", rather than creating something that is overly generic. That is the reason why most start-ups never try to serve entire markets, but seek out niche verticals to start their products in.

But when you've found your niche vertical, and in particular your first customer within this small market slice, that's about when you ought to adopt a fierce customer-centric mindset, which literally could look like you're giving everything they want. Your first customer is key, and forms the archetype of who you'll be coming to serve for a considerable time ahead. In fact, the choice of your first customer is also important - having a reputable first customer serves as a testimonial, enhancing the product's credibility and making it more attractive to potential buyers.

You need to go to the extent of literally developing your product hand-in-hand with this first customer, and treating them as part of your development team or even providing a special first service. It's going to feel as if you're giving into customer demands entirely, but that's where the product manager must make an expert call to balance between what the product vision calls for, and what the first customer is asking for.

When I worked at Circles Life, I remember how the head of engineering team went to meet one of the first few customers of circle life and gave him onsite service at a mrt station. This was clearly over-servicing, and we did it only for our first few customers, because we knew that working so closely with these few early customers would help us shape the product better and get us the advocacy we needed.

-- Wilson Wan, sharing about his experience in the private sector on one of our learning days

In our case, it's quite clear why we chose the Ministry of Health (MOH). I was previously working at MOH, and I knew the problems they faced. To boot, MOH was definitely a reputable ministry in terms of the scale and type of data analytics they performed for their healthcare financing policies. If you are working anywhere within the social sector, you would know what a multi-million dollar problem healthcare analytics was, ranging from finance to HR to clinical domains.

When we worked with MOH, we partnered Wong Wenjie, who was one of the Directors serving at MOH's Healthcare Finance division. Every single iteration of our product was spent addressing his feedback, and we maniacically spent all our efforts designing our product to resolve the painpoints he described. We believed strongly that Wenjie was such an archetypal first customer, we spared no expense in tailoring the product to his requests. The theory of change was simple - once we could successfully solve the problem for MOH, which had such a high bar of success, it would only mean that our product would be fit for the larger public service market.

Within the engineering team, Wilson and Weijun spared no expense in service delivery. We questioned ourselves if it was considered over-servicing when we also set up the data pipelines and resolve certain data engineering issues for MOH before we could implement Sense for them. We even went the additional step to clear MOH's internal security policy forums, and wondered if we were spending too much effort trying to resolve an agency's internal issues, rather than leaving it just to them.

But at the end of the day, we are public servants. If not us, then who? Perhaps it was this principle that inadvertently made us deliver the extra miles, which made us understand MOH's priorities of data security a lot better.

It's fine to start small. But you must always start by creating virtuous cycles in a grand marketplace.

Another golden rule of small agile product development teams is to start small. Always start by scoping down a big problem into a series of smaller problem statements, then attack the smaller ones. This allows you to create smaller products to solve the smaller ones, and this allows you in turn to try fast, fail fast, try again. It's always easier to take in customer feedback and change a smaller product, as opposed to tearing down a super big product and starting from scratch.

While true, where you start matters as well. You don't want to be starting in a place that makes future chess moves on another chess board altogether. As a product team, you need to invest your moves in an ecosystem, so that you can create what is known as a virtuous cycle. A virtuous cycle is one where increased adoption of your product leads to a better value proposition for other customers to onboard your product.

In our case, MOH was a perfect first customer because it allowed us to make our first foray into the social sector. MOH, Ministry of Education (MOE), Ministry of Social & Family Development (MSF) - these social sector agencies were all data-intensive agencies, and we knew that given the policy development in Singapore, they would form a tightly woven policy ecosystem sooner or later. In fact, they are already somewhat of an ecosystem now. With HealthierSG in place, we knew that MOH and MSF would end up serving the serve resident archetypes across their service landscape.

Our grand marketplace was the social sector, rather than just MOH alone. And we knew that once we had MOH onboard, it would be much easier to bring this capability to the other social sector agencies. Generally, health and social service agencies have an incentive to share data with each other for the benefit of their clients – regular citizens, by and large. Giving this capability to MOH would make it easier for them to share data and results with other agencies, which would result in a virtuous cycle where other agencies would also want to onboard the product in order to also share their data with one another.

It's really fine to start small. But you don't want to be starting small in a place where you can no longer expand the balloon.

Your product may well have started out from a certain use case. But you should always seek to expand that use case into an system-level problem statement.

Finally, we always learn from product management courses to anchor our product on a certain use case. If your product doesn't solve a problem, then no one will buy it. It's critical that all products must solve a specific use case, to demonstrate value to customers.

But what no one told you is that the solutions of today will often generate the problems of tomorrow. When your customers' problems are solved by your product, it allows them to think of the next bound in their business plan. And if you're serving the customer, the whole idea of being customer-centric is that you want to be thinking from their perspective as well. Quite literally, you've got to be continuously positioning yourself to ask: once this problem of theirs is solved, what will they be looking to solve next? How can I adapt or evolve my product to suit their evolving needs?

This is what it really means to be maniacal about your customer. You literally think of a product to advance their business strategy.

In the case of data-intensive agencies like MOH, MSF and MOE, we knew that the problem of accessible data analytics was just an internal problem. Once solved, the wider and bigger problem was how to share data easily and securely across agencies. Think about it - if you're performing a policy review that involves datasets across MOH, MSF and MOE, wouldn't you require data sharing capabilities across agencies as well?

That's when we realised that Sense had the potential to go further than just democratising data analytics capabilities within a single agency. We could nudge the trajectory slightly, to evolve Sense into a tool that enables cross-database queries across different agencies. In order to do that, we had to create a robust enough data governance module, that would manage data sharing permissions and protocols tightly, and also look into data sharing adaptors that allowed contribution of data from different databases.

And that's how we managed to shift from "making it easier for policy officers to do data analytics" to "making it easier for policy to be co-created across agencies". We had found the next bound for our product by working closely with our customers, and constantly thinking about what the next big thing for them might be.

It's nearing the end of my term in GovTech. And I hope my team will go on to do more for the public service.

I don't have much time left, as I always tell my team. I'm not so naive to think that our product will survive necessarily, as there are always many products out there that do virtually the same thing. But like I always tell the team...

We're in love with the problem, not the solution.

-- Yong Kiat

I hope to see their products solve more meaningful problems in future.