Product Management at Scale, Part 2
The premise of this ‘talk converted to blog series’ is that the practices, frameworks and methods discussed among and employed by product managers are insufficient at any significant scale.
Go back to Part 1 to get context.
We wrapped up the last post with the assertion that the usual things we talk about in Product Management discourse are important, but insufficient at scale.
I then called out six concepts that need to be addressed to orchestrate product management across large teams. They are; Complexity, Uncertainty, Responsibility, Trust, A Shared Language and Power.
These are the things that program management offices, standards groups and the like are trying to address, although often without consciously knowing that it is these precise things. Perhaps they speak about risk as their unifying idea. Risk is a pretty broad abstraction, though, and as we so often see — when the thinking is at the wrong level, so are the results.
In order to be more precise, I’ll be using these six ideas to reframe what we need to be doing.
Complexity, Uncertainty, Responsibility, Trust, A Shared Language and Power.
Before I get into the instructional part of this talk, I’ll share a story that illustrates some key ideas.
In 2009 I was project managing a software project for a government agency. The agency, like many government departments, had an IT team fuelled by talented people who wanted to good work for their citizens, but were beset by the usual challenges of government; competing agendas, an organisational culture built around compliance and risk avoidance, and never enough money or sustained attention to transcend the tactical.
In this case however, through fortune, an alignment of coincidences, and the sheer bloody mindedness of a few individuals, this organisation managed to pull off something amazing. It successfully completed a multi-year, multi-million dollar IT re-platforming project.
Even more remarkable, it was on budget, on time and even exceeded user expectations in terms of what it could do and how easy it was to use. What happened? Plenty. You could write an opera around some of the drama on the journey. But the thing I want to share with you today is the magic of collaboration and how that plays into our six big ideas.
Complexity, Uncertainty, Responsibility, Trust, A Shared Language, Power
The ITIL challenge
Early in the project, the team that was building the new software solution were blocked from progress because the ITIL driven operations team didn’t have enough capacity to support this new project team. At first, the team were frustrated by the blocker, but then when they realised there were no other options, they asked the infrastructure team what they could do to help make capacity.
Infrastructure teams don’t usually get offered help from Dev teams and in those days there was only so much they would share anyway, but they found some low risk work they could outsource, and share they did. The software team built capacity, and also goodwill.
The user challenge
The second challenge the team faced in this story was getting the users to buy-in to the changes the team wanted to bring. Government IT departments are known the world over for coming in years late, over budget with underwhelming products. The user groups were call centre and process workers who supported citizens wanting to use particular services. They needed changes, and they needed simplification in their workflows. Demand keeps growing, but headcount is limited. You know the story.
(Sorry for the concealing the specifics of the org, but, well… you know how it is.)
Regardless, the frontline workers were lukewarm at best about their interactions with the IT department. Something akin to “I’ll trust you when I see some results.” So the development team gathered some power users and incorporated them into their requirements discussions, and in addition, once they got their first version of working software out, they went and sat with users at each release to observe, support and take feedback.
Being there on the ground shortened the cycle of feedback to the dev team, and also enabled small, high impact things to bypass the usual backlog planning process. An example of this was the desire of frontline workers to tab from field to field. It took less time to implement that change than it would have taken to get it into a backlog, let alone prioritise it against other things.
The steady flow of value, the face to face interactions, and ‘turning up’ with the releases really helped build the relationship between the developers and the user groups.
The regulatory challenge
The third challenge of this story was further upstream in the requirements' hierarchy; the regulators and parliament. The regulators had a similar experience in their careers to frontline users. A lack of direct and intimate contact with the software people meant they didn't know how to best frame requirements, and requirements were often intermediate by someone who only partially understood the real issues. Hello, every BA ever.
As a result, these analysts often built in elements of ‘how’ to solve for things via regulations and laws that went to parliament, and those constraints would make implementation much more complex and difficult.
The lead BA on this project team developed a relationship with some of the regulatory officers and explained the consequences of too strict a requirement. Examples were shared, trade-offs were discussed, and in the end the regulatory analysts became much more oriented to the outcome than the instrument. Without any fuss the regulatory analysts (and the minister, and parliament, probably unwittingly) plugged themselves into the iterative development process.
To this day, this project stands out as remarkable.
It built an end to end product development process that incorporated the IT governance processes, the regulators and parliament and the users into one shared venture. Government IT projects just don’t do that (1).
How did it get there?
The team constantly looked outward and paid attention to the stakeholders and built relationships. They listened to what people asked for and heard beyond the specifics into the intent. They treated everyone in this network like a team member and found the shared desires that pulled everyone together. They got runs on the board.
I’d like to say I led them to success, but in reality my contribution was usually asking basic questions like “So what needs to be done?” and letting the team figure things out. The team are the ones who achieved this great result.
By taking this inclusive view of the environment they operated in, the team went slower in the week to week progressing of things, but they went further and faster at the large scale. And faster than any similar team that organisation (and probably that government) had ever seen to that point.
They built goodwill and trust by listening and delivering. They were able to cut through the complexity of organisational politics and competing priorities by slowing down and getting on the same page about mission, by helping neighbours along the way and by cutting out IT jargon and speaking plainly in the language of the organisation. And they were able to align people and address the power differentials by being consistent, backing up their words with actions, and most importantly, by taking the time to hear the needs of the people around them.
What does a government IT project from 15 years ago have to do with modern Software Product Management? The core principles are self-evident.
A good leader, in whatever context and whatever role, has to also be a good organisational citizen. You can't go out ahead and alone with your small cross-functional team without considering the cost of local optimisation.
Sure, there are exceptions to this, but for 90+% of product managers, you’re managing a fairly mature product in a known market, and you are one of many product managers in your organisation.
You need to be acting as a whole.
In the following posts in this series, I’ll drill into some ideas and tools on how you can do this.
Notes
(1) Government IT projects just don’t do that. (Well, they sometimes do.)
