Recommended
Recommended
More Related Content
Similar to Good Public Sector Product Manager / Bad Public Sector Product Manager - Presentation for Public Sector Network Roadmap for Digital Product Management Virtual Event - March 4, 2021
Similar to Good Public Sector Product Manager / Bad Public Sector Product Manager - Presentation for Public Sector Network Roadmap for Digital Product Management Virtual Event - March 4, 2021 (20)
Recently uploaded
Recently uploaded (20)
Good Public Sector Product Manager / Bad Public Sector Product Manager - Presentation for Public Sector Network Roadmap for Digital Product Management Virtual Event - March 4, 2021
- 1. Good Public Sector Product Manager / Bad Public Sector Product Manager Exploring the behaviours and characteristics of successful government product managers Rumon Carter Executive Director, Exchange Lab Government of British Columbia
- 3. Hi.
- 13. “The Exchange is leading the way, not just for Government IT, but for all large enterprises.” ~Jeff Walter, Deputy Head / Data Systems Engineering Lead NASA, May 2019
- 18. On Being a Good Product Manager
- 22. Good product managers are product owners.
- 23. Good product managers focus on outcomes.
- 24. Good product managers communicate clearly.
- 25. Good product managers are proactive.
- 26. Good product managers are results- oriented.
- 27. Good product managers are pragmatic.
- 28. Good product managers are strong strategists.
- 29. Good product managers craft their own roles.
- 30. Good product managers are disciplined.
- 31. Good product managers are relentlessly aspirational, generously self-compassionate, and a continuous work in progress.
- 32. ^
- 33. We work in, we dance with complexity
- 34. Good product managers – the purposeful, agentic, masterful hubs of high-performing teams – are our future.
- 35. Good product managers are connected and contribute to a growing, generative community
- 36. Good product managers are you. Good product managers are us.
Editor's Notes
- Good morning, afternoon or evening from wherever you’re joining today, friends. As we gather, I would like to make a few introductory comments. First, for those who haven’t met me, that’s me, in the red, looking slightly crazed, propping up a teammate. Before you get worried, though, I promise there will be none of that kind of behaviour today – that this isn’t how I typically show up to work … though I admit I do do my best to show up with max positivity and a desire to support others, in a variety of ways. I’d like to throw out a couple of shouts before setting out. First, to Olivia from the PSN Canada team for the support with set-up. And also, acknowledging a bunch of BC peers in the audience, calling out a couple, who I’ll mention again in sec – Heather Remacle and J-P Fournier. They’ll be monitoring the chat as we roll here, so please fire any questions in there as we go – apropos a theme of my talk, they have my complete trust and autonomy to answer them.
- Next, this I’d like to introduce you to my home, as seen before an ocean dip yesterday morning. When I do show up to a gathering such as this, for the past year it has been from a place close to here, at the shores of the Salish Sea, an incredible, history-rich place that it is my privileged to call my home. Today it’s called Victoria, British Columbia, but it was and remains the traditional territory of the Lekwungen-speaking Peoples, and I acknowledge and give thanks to my forebears for their history on and continuing stewardship of this Land, Sea and Sky.
- Last, I want to give acknowledgement to the times we are inhabiting together. We’re approaching a year since most of us went home, to work at our kitchen tables, doing our best to establish a balance between corporate responsibilities, Cabinet submissions, child care and, maybe, just maybe, some semblance of self care. And the virtual meetings … ALL the virtual meetings. I want to acknowledge that I see you and am grateful to be in it with you, weary as we may be. In that context, I am especially glad for the honour of your time today. Coincidentally – or perhaps not – last night my teammate Derek posted an article from Apolitical by Australian Stephanie Moorhouse, titled, “A benediction for the weary public servant.” In it, Stephanie observed: “As I write from this place of deep weariness, I ask: “What is it that I myself want to read?” The answer I come to is this: words that nourish. … right now, I crave words that provide a balm before I can face another tip sheet, webinar or guide with any genuine enthusiasm.” I take that to heart here as we set out here, and will do my best to nourish somewhat with our 20-minutes together.
- And I take comfort from the fact that we know – thank you, Daniel Pink – that what motivates us, what nourishes us, in our work and otherwise, exists at the intersection of Purpose, Autonomy and Mastery. And if there is anything that properly defines the subject of my talk today – the expression of the role of Product Master - in my opinion, it is an individual who has – who has taken, who has created, who has been granted – purpose, autonomy and mastery. To be a product manager is to nourish a team and to be nourished by that work and its character. I will do my best to convey that today.
- But who am I to be here with you today, why does conveying my opinion matter? What qualifications do I have to speak to you about product management and the Agile methods and mindset that surround and are expressed by the role? I owe it to you to be honest with you….
- I am not one of the – based on this photo from the gathering, apparently all white, middle-aged, slightly portly (ok, I am all those things) – men who met on February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, to develop what came to be the Agile 'Software Development' Manifesto.
- I am not showing up today purporting to be an expert. I have not written a book on Agile.
- My best credentials for agility, if I’m being honest, come in the form of times like these, balancing my step-daughters’ bodies and emotions somewhat precariously in a canoe while we paddle – and line through rivers – on multiday backcountry adventures.
- Heck, even if I was once technically qualified to be a product manager, I am no longer.
- So what am I qualified for? Why am I here?? I’m here because I’m the leader of this rag-tag band of BC public sector change agents from inside and outside government, sharing potluck and a team-of-teams retrospective learning session in pre-pandemic times. That’s me, over on the left, convening the conversation as co-founder of a place and a program and – most importantly, a community – called the Exchange, which has emerged over the years from its place at the edge of the British Columbia government as a hub of effective, delivery-driven government. So, if I can’t look to the Scrum Alliance to qualify me…
- … I hope I can look to NASA to do so.
- And look to our partners to make my credibility case – our credibility case – now six years in the making but very much punctuated in the past year, of what it takes to design and deliver public services with pace, intention and quality. To solve meaningful problems not in months or years, but in days.
- To work as that team-of-teams, which gathers still, through this pandemic, now virtually, to support each other to support the citizens of BC with the things they need. Like their COVID-19 test results. Like their immunization records. It’s those results – for which, to be clear, all credit rests with the teams in our community that built them – from which I hope I can earn your trust to speak to you today. Because …
- While it’s been over 3 years since I was actually on one of those delivery teams delivering those results, I’ve been at their centre – coordinating them, supporting them, cultivating the soil in which the fruits of their labour might flourish. That’s our role at the Exchange Lab, which you can see expressed here in a couple of models that guide our work. On the left is Marshal Ganz’s Snowflake Model for campaigns and community-building, used by Barack Obama to win the Whitehouse in 2008; on the right, specifically at the bottom, is General Stanley McChrystal’s Team-of-Teams model, which is an expression of a form of network governance. How we organize is a whole other topic for another day – or days – but the point here is that we exist as the hub supporting and about which spin a growing number of spokes. And at the centre of each of those spokes, at the core of each of those high-functioning, cross-functional teams, is a Product Manager.
- Someone who looks like this. And, I pause to make clear, other someones who don’t look like this, who don’t look like me. It is one of my most significant points of pride to observe – admittedly only anecdotally – that delivery teams orbiting the Exchange Lab are the most diverse group of people I have ever encountered in the BC Government, which is very much by intention and design, as we seek to adequately represent the rich, beautiful diversity of people we serve in the province. But this particular product manager, whose name is Matthew Hall, today the product manager of BC’s Mines Digital Trust team - which is working on the responsible sourcing of minerals, in service of Environmental, Social and Governance outcomes – is the one of whom I had on hand the most enthusiastic-looking photo on-hand. Which is admittedly a pretty standard look for Matt.
- So let’s get down to talking about what it takes to be a Good Matt, or a Good Matilda. As we do so, let me explain why the title.
- Twenty two years ago, Ben Horowitz, an American technology entrepreneur, wrote a seminal article on what it means to be a technology product manager – he titled it “Good Product Manager, Bad Product Manager.” Despite the passage of time it is still today required reading for commercial product managers. I’d read it years ago, but a year and a half ago my now-teammate – who at the time was working in a start-up tech company – J-P and I tripped over it again. We acknowledged that while it was good, if a little dated, it was understandably focused on the manager of commercial products. We looked around, and while an increasing amount has been written about public sector product management, we couldn’t find an equivalent, so we got down to writing one.
- We took our typical approach and got all Jackson Pollock on a whiteboard – for clarity, this isn’t what we produced; instead, it’s the genesis of BC’s digital strategy, care of my other teammate Heather Remacle’s brilliance. But, like I say, that was back in December 2019 … and then … well, 2020 happened. So when the PSN reached out about doing this talk I rallied J-P and Heather and said we had to finish the damn article in support of this session, which earlier this week we did, and posted it to Medium …
- … but today you get the live, in living colour version – a version, if you will, of the standing CUT Squad (that’s: Citizen User Testing Squad), also known as the “Patient Voices” group, that our Health Gateway team engages with regularly to make sure their service is fit for its intended purpose. So let me show you some production product; let me share with you our sense of the characteristics of a “Good” Product Manager, and I’ll get your feedback for iteration at the end, or at another time in the comment under that article.
- Let’s get this out of the way first. A bunch has been written about the distinction between product managers and product owners. We could spend an hour splitting hairs on that topic alone. But we won’t, and we didn’t in the article. For the sake of alignment with Horowitz’s original, we used the term “manager”; however, the term we use in BC is owner, and very intentionally (after, honestly, a couple years going back and forth on the topic). Why? Because a product owner needs to have, to express, to lean into that autonomy I mentioned earlier – and do so with the attendant responsibility and accountability. If the person leading product design and development doesn’t have a direct line to their users and the ability to respond with pace and intention to their needs, absent the typical weeks’ or months’ long gauntlet of typical bureaucratic, waterfall “governance,” this way of working won’t work. So a good public sector product manager is a product owner. And 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. 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 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 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. 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 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 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 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 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. 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. And, finally, painting outside the lines of Horowitz’s original, and in so doing seeking to make explicit what the authors hope was already understood here…
- Good product managers are relentlessly aspirational, generously self-compassionate, and a continuous work in progress. In other words, if measured against the foregoing, neither I or my co-author teammates would be 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 so, please receive all this as we intended: As a humble offering of my team’s 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, set out in the way I did here, 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. And a related note, connected to product management but also true more broadly …
- Just as I am not the guy with the pieces of paper to qualify him for this talk, I’m not suggesting that there is only one way to be a product manager. Increasingly, we get asked by others – inside and beyond our government – for our playbook, for the recipe book for how we got our results. This humbles us, and as community-minded folx with principles of openness and defaulting to re-use, we are only too happy to share what we’ve learned and compare notes with other learners. But the thing is: There is ultimately no single playbook for how to do this work. Following, step-by-step, a Digital Service Standard will not necessarily produce a high quality digital service that meets its users needs.
- Because our worlds, and our work, are highly complex. Any difference that exists between your context and mine will ripple, deviate and magnify through your system, such that if you were to exactly replicate what we’ve done the past few years you would get radically different results. Which is ok, which is what we want – because it is through this diversity of people, approaches and results that we will be best situated to learn, to adapt, to maintain our resilience, to fulfill our privileged positions of earning public trust through responding to the needs of the people we serve. To close, if I have seen and learned anything from my years in this work, if there is one thing that I believe I can know to be a key requirement of this way of working, of this success, of the renewal of public service that I believe we all exist within and are shaping today …
- … it is that the path to that positive future runs through supporting people – product managers and the people who surround them – to lean into their gifts, with purpose, autonomy and the shared pursuit of mastery of this craft of public service.
- Shared. Because while humble autonomy to lead and learn is a key characteristic of the good product manager, none of us does this work alone. It is only through our connections, through our sharing, that we will grow, learn, succeed, and fulfil our roles and our delicate public duty.
- That’s what good looks like from where I’m sitting. It looks like you. So here’s to us. To our OneTeamGov team of teams. To supporting and nourishing one another – especially during these especially challenging times. I hope I’ve played some small part in that today.