Who are you writing for? Clarifying your target audience, their interests and their goals is an excellent start. Once you have a rough area in mind, read about it! Even if you’re an expert in the area, it’s worth building a picture of what others are writing about in the space.
I think that the issues for withholding data boil down to essentially how easy it could be to de-anonymise data (fair question), who would you hire to be the archivist for this and where do they sit (easy question), and how do you deal with qualitative research that contradicts a policy or, say, a democratic vote (no idea, but we should be talking about this).
On the first point: there is no publication of user research in government beyond, potentially, a blog post with insufficient detail. Let me repeat that: the government spends money researching how a service could help, how to build it, how to improve it and some deeper life stuff about the needs of the service users and it will inevitably languish on a google drive somewhere rather than being shared (anonymised) either with other teams, academics or the public. Qualitative data is still data, and more data about the practice of government should be open.
Working on delivering public services can be a patrician process. Even with researchers, policy people and ministers from a democratically elected government, you can end up missing a layer of democracy, and you’re deciding whats best for citizens in an artificial environment. Sure, there’s research to check whether you’ve built the right thing or, if you’re lucky, to suss out the design constraints of the project before you start, and all research is better than no research. But often, there are institutional barriers to research that could challenge a policy direction, or create a project that costs too much. This isn’t to say that those things aren’t valid reasons, but to say that the way that we understand qualitative research as a source of popular authority then rubs up against the democratic design constraints that are also meant to serve the interests of The People.
Have you heard someone high up in your organisation or one you (used to) respect spend their time on some manel talking about robotic automation or AI or ML? Me too. The weird thing is that I’ve never heard them talking about the number of temps you need to hire to clean the data first. All of these c-suite boner outputs sound great, but are built on the back of the biggest vapourware product ever: clean data.
The world is littered with thousands of companies who made it past their first successful product, but were unable to transition to a platform or launch a successful second act. There’s great content on the web detailing product management of shiny new products & features using MVP / prototyping to get ideas off the ground, but very little on making the shift to scalable infrastructure that’s built to systematically launch new products and grow your business. Understanding how platform product management will change your product organization and your company can be the difference between an organization that’s built to last and a one trick pony.
The desire to be a platform is great, having the architectural leadership in place to execute on this is very different. I won’t go into the definition of a great software architect, but having a few pragmatic, thoughtful architects in your org to avoid complexity and lead conversations with PM’s and software developers is a necessity, because they truly understand what’s possible. The architecture team must have a holistic view of the entire system in mind when they help the PM make decisions. Great Platform PM’s know to engage the architects early and often in researching new development.
When I’ve switched to a platform environment, I noticed a change in the way much of the engineering organization thinks about product development away from customer centricity. Prior to building a platform most product teams were fully cross functional. In a cross functional world, our engineers were spending time talking to customers with product managers and designers. Once we switched to a platform model where teams of engineers would own an API, we had entire teams working on good computer science problems, but not speaking to any customers for months on end. In the worst cases, we had teams of developers over-architecting a solution that customers didn’t really need in the first place. Customer empathy is something the platform PM needs to find ways to generate. Too often a platform team believes that if they provide value to internal stakeholders or other developers, it’s good enough. But it’s the combination of customer needs, stakeholder needs and developer needs that make for a great platform. In this sense, the voice of the customer becomes even more imperative for a platform PM.