Value. Workflow. Quality.
If you had to pick one, what’s the defining purpose of being a product manager in government?
According to long time product leader Scott Colfer, who has worked in both government and non-government roles in the United Kingdom (UK), it’s value.
While workflow and quality are necessary, mandatory, non-negotiable aspects of a well functioning digital product team, they are not sufficient in product management as a whole. Without a better understanding of value, we risk the “nice landing, wrong airport” scenario of having done things right, but not doing the right thing.
This came up through a recent retrospective and some great conversations with colleagues within digital government initiatives. I’ve since been reflecting a lot on the centrality and importance of product managers in our work with government building digital services.1
Here are a few things I’ve noticed that might help us enable a better understanding of value and the role of a government product manager.
Product management is still new in government and unevenly distributed.
My best guess, based on the available data, is that the British Columbia (BC) government has fewer than 60 official product manager roles. There's likely also an unknown number of individuals performing similar duties without the formal title.
The novelty of the role means it’s not well understood in the organization and at times not well understood even by the person occupying the role.
Every product manager that we’ve worked with over the past few years has brought their own unique strengths to the job. Reflecting on their product management origin stories, it has often been the case that they were in a well-defined role prior to their product manager job, typically a subject matter expert within the domain we find ourselves subsequently working. Along with the need to design and build a new thing (or things), came an opportunity to occupy a new role to help lead, coordinate, and deliver. A government product manager is born.
Some possessed capabilities that align with the government product manager job description. Some had managed products before. Others had never been part of a team designing, building, and launching a digital product or service in their career to date.
Much like the historic emergence of user experience (UX) jobs in government, when the public service adopts new practice and builds new capabilities, someone has to go first.
Our product manager peers in government have been courageous in putting themselves forward to take on that challenge. For those that went first, there have been some great strides in reflective practice and learning in the open (not a surprise from these three in particular who favour working in this manner…).
Because product management is novel and misunderstood, it risks being overloaded.
I think it’s uncontroversial to say that product managers juggle a lot in the course of their day. Some of that is the very essence of the job. Yet some of it feels like product managers, because of the novelty of the role within the organization and their own lack of prior experience in the role, become overloaded with responsibilities. These responsibilities would better be suited for another role or even a series of roles (e.g. change manager, quality assurance manager, service owner, full-time-exec-stakeholder-wrangler, and meeting attender…).
We’ve seen product managers doing all the things everyone else avoids doing. We’ve seen those further up in the hierarchy delegate tasks and responsibilities to product managers not because it’s what the job entails, but because some task is new or novel and because it’s new, then it must also be part of product management, right?
And we’ve seen the effects. When combined with a product manager’s responsible disposition—the fact that they care about the product, their team, and the impact the government has on citizens—we’ve witnessed product manager overload, burnout, and even product managers quitting their teams.
Product management is a variable role across the lifespan of any given initiative.
Back to Scott Colfer’s work on product management in government, he writes, “product management is responsible for value. Our teams require at least three perspectives if they are to work well: Value - Workflow - Quality. Product management’s focus is optimizing2 value, and so is most useful to an organization when we are given responsibility for value.”
Great product managers hold the value-workflow-quality triad in tension, negotiating their way amongst the competing commitments inherent in each. Yet during the lifespan of any given product/service initiative, these areas of focus are not always equal.
In the design-build phase of a product yet to be released to the end-user or citizen, be it an internal enterprise application or an externally-facing digital service, it’s hard to demonstrate value. Deadlines, promises, and fiscal year-ends are likely to be more of a concern pre-launch, along with the hard questions of what constitutes sufficient quality across all of the dimensions of a product (frontend, backend, etc.) in order for it to be released.
As one colleague remarked, “We find this especially hard in the public service where minimum viable product (MVP) is often impossible to deliver in increments, starting small. Our products are usually only serviceable as MVP when they’re damn near the whole thing. So much for skateboard, bike, car…”
Once a product goes live or even enters a beta phase, staggered release, or roll-out, increments of functionality and ensuring workflow may continue to dominate the attention of product managers and their teams as observing and measuring value continues to be elusive.
Delivery/workflow-oriented product managers have great metrics available to them at this stage like the Accelerate/DORA concepts of cycle time, deployment frequency, mean time to restore, and change failure rate, but knowing whether or not your product-service is having an impact on the lives of citizens across the province or employees within the public service… Not only does it feel harder to measure, it's scary to think the answer may be “no” or “not enough.”
Yet that’s exactly what product managers need to do.
If they aren’t focused on value, then who is?
It’s not personal, it’s structural. So how do we fix some of the structural?
The challenges I’ve noticed are not based on the shortcomings of the individual product managers we work with. By no means is this intended as a critique of the courageous and skilled people we collaborate with every day. Instead, it’s looking at the conditions and barriers that exist within government, trying to better understand how to enable value-creating behaviours.
What are some of the forces at play that influence those behaviours and how the role is enacted in government? A possible starting point for that inquiry is at the beginning: the job description that articulates the knowledge, skills, and responsibilities associated with the role and what is required to perform the role well. I’m curious to know, how do these formal definitions of the work to be done line up against these ideas of value, workflow, and quality?
That’s where I’m asking for your help.
If you’re a product manager or occupy a similar product-adjacent role (product owner, scrum master, project manager—noting that titles and roles are still in flux for this type of work depending on where you work), I’d like your help in looking at a sample BC government product manager job description (PDF) through the lenses of value, workflow, and quality.
I’ve set up a small activity that will help shed some insights into the role’s accountabilities and what that might mean in enabling more value-oriented work to occur.
After I receive enough responses, I’ll summarize what I’ve learned and what I believe to be some possible ways forward.
Please consider contributing 10 minutes of your time to help.
Share your thoughts on product managers and value enabling behaviours
Footnotes
- Noting the small linguistic disconnect there: product manager/digital service.
- As a more service-oriented person, I’d love to suggest the focus should be on co-creating value, rather than optimizing value, as the former suggests value is something that perhaps inherently exists somewhere, like it's an attribute of the product that can be engineered. Co-creation implies value exists between the interactions of provider and consumer, nudging us to always return to the lives of those who use our services and the benefits of the service (back to the ideas of helping someone do something and what government is for).