Good Public Sector Product Manager/ Bad Public Sector Product Manager (Annotated)

A Contemporary, Re-Focused Take on a Classic

(This is a 10' longread, setting out the background and rationale behind the main article you’ll reach in ~ 5 of those minutes. If you’d like to cut straight to the chase you can scroll down or click here.)

All history, in all likelihood, is revisionist. Human memories are imperfect; our stories are our best attempts at approximate records, shared learning and envisioned futures.

Acknowledging this, in the short history of delivery-driven government in the British Columbia Public Service, the three co-authors of this piece — J-P Fournier, Heather Remacle & Rumon Carter — are part of a pathfinding community in that government. They were among its first wave of product and delivery managers, in-sourced talent populating British Columbia’s imperfect early attempts at agile product development. At the time, those ways of working were generally policy-barred, this group having an enabling exemption from their government’s Chief Information Officer to work in these ways, and to hire the necessary types of digital talent to support this work. All three have stayed with the movement and now humbly sit at its center, part of the team responsible for British Columbia’s hub of digital-era government, the Exchange Lab.

What follows is a product of their collective learning to-date and an invitation to join them in the shared work of being continuous learners — always perfecting our crafts, but never perfect — perpetually working for better, striving for Good.

Introduction:

Twenty two years ago, Ben Horowitz, an American technology entrepreneur, wrote a seminal article on what it means to be a technology product manager, “Good Product Manager, Bad Product Manager.” Despite the passage of time — and Horowitz’s more-recent disclaimer questioning its contemporary relevance — it is still today required reading for commercial product managers.

And outside the private sector context? The public sector is a far more recent “habitat” to be populated by the product manager “species.” How does such a creature interpret and apply to their context the commerce-focused language in Horowitz’s opening line and beyond: “Good product managers know the market, the product, the product line and the competition extremely well…(emphasis added)”? Where does the government product manager/owner¹ look for public sector-specific guidance?

We get asked this and related questions often in our work at the Exchange Lab. People ask for the playbook(s). Our commercial partners have started offering to sell to jurisdictions elsewhere versions of what we’ve established as a collaborative community in Victoria, BC. We hear public executives saying to their staff, “I want one of those.”

However, we’ve come to appreciate that it’s not that easy. None of it is easy. Like any complex system, we’d suggest that our little delivery-driven government community can’t simply be reproduced. We had circumstances, barriers and accelerants that were all unique to our context. We’ve had the benefit of years of hard knocks, learning, and the humility that comes — whether naturally or forced — along the way.

On the other hand, we do believe that the atomic unit of our delivery community, the component at the core of its connection and success, can be reproduced. As our forebears in the UK knew and shared, “the unit of delivery is the team.” And at the center of that unit, the axis about which it spins, is its servant leader, the product manager.² But this individual isn’t a unicorn that magically appears or can be conjured. Few if any of British Columbia’s early product managers had a background in technology, generally, to say anything of agile development, more specifically. We were, and remain, conservation officers, mines inspectors, lawyers, farmers, MBAs, and the occasional moonlighting singer/songwriter.

Our Objectives:

Acknowledging all this, and wanting to pay forward some portion of what we’ve learned through our own failed attempts at being good, we set out to draft a modern update of Horowitz’s classic, specific to the public sector context.³ In what follows we explore the unique context and challenges of the government product manager, acknowledge the fact that this role is still relatively new to many governments (unfortunate to note given the passage of two decades since Horowitz’s original article), and hope that from this first offering we can all set an intention to lean into its improvement, to the unending ambition of being better, together.

Our objectives were and remain three-fold:

• To honour and offer commentary on how we see the public sector product manager as distinct from its private sector counterpart;
• To make open and legible what we have learned in that regard, and to invite commentary and improvement on what we offer below; and
• To set out a call to action to our peers in the public sector: We need Good public sector product managers. We need you occupying these roles and leaning into their challenges. We need you to lead this movement forward.

Our Offering, Our Call to Action:

And, with that call to action for you to lead us, we humbly offer our sense of where we may all wish to go, based on where we’ve been, what we’ve learned, and what we’ve aspired to, these past few years. We’ve done so, written in the fashion we have, in order to provoke a response from a place of positivity, to catalyze constructive disagreement and to invite continuous improvement. Because we don’t see ourselves as experts; rather, representatives of a growing group with arms linked as we collectively seek to cross a river by feeling the stones. It’s neither our general disposition nor our belief at this specific stage in our joint evolution and learning that any product manager in our midst is “Bad.” Truly, we’re all just working — together — to find our way towards Good.

We extend our thanks to Ben for setting out a path for us to follow and to riff on, as well as our hope that anyone interested in solving public challenges in this digital era that we all inhabit will read on and join in.

¹ A note on language: Much has been written about the (ostensible) distinction between product “owners” and product “managers.” Debating these distinctions is beyond the scope of the present article; however, it is a topic we anticipate returning to another time. For now, for what it is worth, the authors have oriented their own lexicon around the term owner, based largely on the agency and responsibility that we believe and have witnessed the effective fulfilment of the role — no matter how named — requires. Nonetheless, for the sake of consonance with Horowitz’s original, we have stayed true to the use of “product manager,” though you will see reference to ownership in one of the opening paragraphs.

² A note on teams: Just as no person is an island, no product manager has function or meaning without a team. That said, in our time working in digital delivery in government, we have found product managers to be the hardest to find, to cultivate and for whom to garner from those around them support for the proper fulfilment of their roles. It is for this reason — apart from our appreciation of Horowitz’s original and a desire to do it homage — that we have focused on that role in this remix. We anticipate returning to discuss the patterns and antipatterns of other roles another time.

³ A note on process: In taking on this exercise we broke down Horowitz’s original material into a set of themes that we used to form the structure of our own update. We did this in the interest of best drawing parallels, updates, and inviting comparison and commentary. While these themes aren’t explicit in the content that follows, in the interest of being open about methodology we created a second document that provides a map of our new content compared to Horowitz’s “old.” You can find that map here.

Good Public Sector Product Manager/ Bad Public Sector Product Manager

Good product managers are situationally aware.

Good public sector product managers understand user needs, the political environment, the policy and the product, and operate from a strong basis of knowledge and confidence.

Good product managers are product owners. They understand the outcomes that they are trying to achieve. They understand the context going in (political direction, budgets, internal resistance, etc.) and they take responsibility for devising and executing a winning plan (no excuses).

Bad product managers make excuses. They blame the policy director for not getting it. They call out stakeholders for not trusting them to make decisions. They feel micromanaged. They accuse the IT department of treating the work like a back-office IT project.

Good product managers focus on outcomes.

Good product managers are not split across several projects and don’t sit in meetings all day. They prioritize and delegate so that they can focus their time on users, the team and the product.

Good product managers are not required to be “Subject Matter Experts” from “The Business”. They are not engineers, project managers or business analysts from IT. Delivering citizen-facing products and services is not the same thing as delivering commodity IT, though both are important.

Good product managers build and empower diverse teams — including design, policy and engineering — to uncover and respond to user needs. They define a clear vision with objectives and simple, measurable results. They manage the delivery of outcomes, not outputs.

Bad product managers get sucked into the weeds trying to figure out the “how”, and manage for outputs, not outcomes.

Good product managers communicate clearly.

Good product managers communicate crisply — both verbally and in writing — to their team and key stakeholders. They don’t give informal direction. Good product managers constantly gather information about users’ needs, organizational priorities and their political environment.

Good product managers communicate proactively. They build trust by working in the open; anyone can learn about their product in real time with just a few clicks. They write the story they want told by their peers, superiors and public affairs departments.

Good product managers clearly explain the context, purpose and important background information. They always avoid buzzwords and err on the side of clarity.

Bad product managers get lost in minutiae. They communicate in detail about specific features and technologies.

Good product managers assume their executives, communications people, the public and the press are really smart, communicating with them as such.

Bad product managers assume these people are anachronisms and don’t “get” technology.

Good product managers are proactive.

Good product managers are proactive. They anticipate issues — technical, political or otherwise — before they arise.

Bad product managers spend all day putting out fires and fielding requests from politicians and executives. Their teams are feature-obsessed and their products are riddled with technical debt.

Good product managers know that outdated standards, policies and laws can be changed. They dedicate part of their time to shaping and modernizing the system within which they operate. They write about important issues, share the stories of their teams and contribute to policy modernization efforts.

Bad product managers lament all that is standing in the way of delivering good products. They complain about people who don’t get it, antiquated policies and overly strict standards. Once they fail, bad product managers blame “the system” or “the bureaucracy”.

Good product managers are results-oriented.

Good product managers measure their impact using objective success criteria like user uptake, completion rates and cost per transaction. They automate the collection of these metrics and publish them in the open to focus their team on valuable outcomes, not outputs.

Bad product managers lose sight of outcomes and instead only track scope, schedule and budget. They use change orders to re-baseline these so they always appear to be on track.

Good product managers are pragmatic.

Good product managers think big but start small. They clearly describe the context, purpose and common goal for their team. They define good products that can be executed with a strong effort. They set clear parameters around product decisions that they can make, tactical decisions the team can make, and policy decisions that executives or elected officials must make. They say “no” much more often than they say “yes”.

Bad product managers provide vague direction and let their team build whatever they want (i.e. solve the hardest technical problem).

Good product managers are strong strategists.

Good product managers understand how to decompose products into component parts. They understand that some of these components should be built; others copied, reused or remixed; still others consumed as a service. They also understand that to manage these different components effectively calls for using a variety of appropriate methods.

Good product managers, in other words, recognize that a cult-like devotion to custom development will not actually save the world.

Bad product managers dogmatically apply a single approach to all problems and work in isolation.

Good product managers craft their own roles.

Good product managers define their job and their successes.

Bad product managers constantly look to the team or their superiors to be told what to do.

Good product managers are disciplined.

Good product managers are disciplined. They always show up early and never forget to send their updates or submit their status reports on time.

Bad product managers are always late and forget these things because they aren’t disciplined.

Finally, painting outside the lines of Horowitz’s original, and in so doing seeking to make explicit what the authors hope was already understood:

Good product managers are relentlessly aspirational, generously self-compassionate, and a continuous work in progress.

In other words, based on the foregoing, none of the three authors are good product managers on any given day. We’ve all missed weeknotes, made excuses and burned days of a sprint’s productive effort on reactionary fire-fighting and busy-work. But we’ve seen — on good days, demonstrated by the great people with whom we’re privileged to work — the good that we’ve described above. We’ve seen the great results that follow. We celebrate and we want more of that — for ourselves, for the benefit of our teams, and for the positive public impact that will follow from these efforts. And, if we know anything for certain, it is that…

Good product managers are connected and contribute to a growing, generative community — one that is committed to shared learning, shared values and the deep and lasting meaning that comes from sharing in positive public impact.

We are grateful and privileged to be here with you, part of a #oneteamgov team-of-teams, and look forward to your suggestions for making this article better.