Head of Product: have empathy, avoid dogmatism

Use and implementation of product leadership roles like Head of Product can vary a lot, as we’ve previously noted. We’re going to take a look at what Head of Product might look like in an enterprise with mutliple business areas.

Product management is often described as a role which is about influence, not authority: Head of Product is no different. You are likely to have at least two version of your role when working in government, one of which you will give you some authority, and the other in which you will need to seek influence:

Head of Profession - The space where you have clearest responsibility and authority is that of the product profession itself. You are responsible for the the performance of the product management profession and the product managers within in. This includes owning and improving the role of ‘product manager’ itself, plus the recruitment and performance management of product managers. You are the most senior representative of the profession, responsible for making sure that it meets the needs of our colleagues - which sometimes requires challenging assumptions about the role and supporting the use of other professions. This role is similar to all other heads of profession
Head of Product - Product managers in government are responsible for the value of public services or the features of public services. You are the most senior representative of value strategy in your role as Head of Product. Government is still unfamiliar with product management and its application outside of delivery teams, within management and leadership teams (we are seeing our first Directors of Product and Chief Product Officers being hired in government departments). As a result of this, you will need to seek opportunities to support and influence value strategy at an organisational level and are unlikely to be given clear authority. This is covered to some extent by the head of product role description on GOV.UK.

Our job is to improve the value of public services. Our scope is often the digital, technology, or data features of these services. It is important to remember this when thinking of the value of our work - it often needs to sit in a much larger context, and we need to be conscious of optimising one feature of a public service at the cost of passing a problem downstream to an operational team. If optimising a feature of a service does not show a real improvement in overall value for users of that service then we should question whether it’s the right thing to do.

In all of this we need to have empathy and avoid dogmatism. Many digital teams are large enterprises, the departments they’re sat within even larger. We work in multiple contexts at once - if you can’t work with organisational complexity then government in 2018 is not the right place for you to pursue your career. As Head of Product you need to acknowledge these different contexts, retain focus on our unique selling point as a profession (improving value through value strategy), be aware of our limits, and seek opportunities to:

Support and influence value strategy at the organisational level, work with Heads of Business Units to empower Lead Product Managers to do the same at a local level within their own business units
Work with, support, and learn from the other value-focussed professions so that we all align to similar goals and make the most of our time and expertise
Work with, support, and understand more about the professions focussed on workflow and quality, so that you don’t over-optimise for your own profession and allow a narrow view to blind you to bigger goals.
Most importantly, work with central leadership and leadership of local business units so that the product professions really helps your organisation to accomplish its missions.

What we needs is principles & trust, derived from clear visions that help us understand user-focussed objectives. What we don’t need is dogma, and we avoid dogma with empathy. The Agile Manifesto for Software Development describes this as “individuals and interactions over processes and tools”.