Prologue

It’s December 2016. People keep asking me if I’m OK. One of them is Georg, our executive coach. We chat in the kitchen. After a pause he says “Scott, are you OK? You look exhausted.” From behind tired eyes I let him know what’s on my plate. In the last 12-months I’ve shifted from Senior Product Manager to Lead Product Manager. And then to unofficial Head of Product. I’m managing 15 product managers. I’m also managing a couple of Web Operations Engineers for good measure. I’ve just completed five simultaneous recruitment campaigns. And remain hands-on product manager for two teams. This was too much for one person to do. I was burned-out.

Georg suggests I make time to have a chat with him to see if we can improve things. A few days later we meet in the week before the Christmas break. And so began my real development as a product leader.

Introduction

There’s plenty of guidance and training on product management. There’s little on product leadership. And common to many of my peers, I’ve never had a product leader responsible for my support and development. This has led to lots of self-motivated digging, trial, and error.

I’ve also found that product leadership roles can be misunderstood and under-used. Senior and Lead Product Manager can sometimes mean ‘busy product manager’, in practice. ‘Head of Product’ can sometimes mean ‘glorified people manager’ in practice.

We need to figure out what product leadership means and explain it to our colleagues asap. No pressure.

Chapter 1: Leadership

Following our chat in the kitchen, I had leadership coaching sessions with Georg in 2017. The first thing I wanted to figure out was what good leadership looks like. I wanted a handle on general leadership before getting stuck-in to product leadership.

Georg recommended I read Management 3.0 by Jurgen Appelo. This book helped me define the type of leader I want to be. It also helped me define the kind of leadership I want to avoid. It comes highly recommended. The short version is that modern leaders need the ability to do the right thing in the midst of complexity. They need to avoid hierarchical leadership and ‘meme leadership’.

Let’s explore this further.

Leadership 1.0: Old hierarchies

Organisations designed around hierarchies are managed in a top-down fashion. Power is in the hands of the few. People at the bottom have little money, few responsibilities, and little motivation to do a good job. This is often described as ‘command-and-control’. It is often mistakenly likened to a military-style structure. In reality, the military abandoned this approach many decades ago. This type of leadership can function in conditions of high-certainty and low-change. It is poorly suited to conditions of low-certainty and high-change. The organisation’s workflow is dictated by the capacity of the small number of people allowed to make decisions.

The Government of the United Kingdom is around 800 years old. But times, they are a-changing. The information age has seen massive and rapid change. The relationship between the public and Government in the UK has irrevocably changed. The public has much higher expectations of public services today than was the case in the past. The UK’s Civil Service is undergoing significant improvement to keep-pace with this change. The Chief Executive of the Civil Service has challenged Civil Service leaders to leave old hierarchies behind and embrace a new type of leadership. In his Civil Service Transformation speach in early 2018 John Manzoni said:

“We need leaders with empathy, who can manage their teams through transformation and encourage continuous improvement. Leaders with broader experience, who are effective in a complex, multidisciplinary world, who lead with their hearts and their guts, as well as their heads, who see the big picture. Leaders whose instincts - developed through experience - are collaborative; who are used to working across boundaries, confident beyond their own professional area, and inspire and empower their teams.”

I need to avoid command-and-control leadership. Instead, I need to aspire to empathetic, collaborate, empowering leadership. This will help build an organisation that can respond quickly to change.

Leadership 2.0: Meme leadership

There are a lot of leadership fads. To summarise and paraphrase Jurgen Appelo, they act as add-ons for hierarchical organisations. These fads ease the problems of an organisation without fundamentally changing leadership. He gives Six Sigma as one example. Jurgen describes this kind of leadership as ‘leadership 2.0’. It is leadership 1.0 (old hierarchies) with add-ons (fads) to release pressure built up within an old system.

I like the word ‘fad’ but think ‘meme’ works even better. Simon Wardley has used the word ‘meme’ to describe leadership strategy, and it’s stuck with me. ‘Meme’ is more forgiving than ‘fad’. A fad is a ‘trivial fancy adopted for a while with irrational zeal’. A meme is ‘a unit of cultural information that is transmitted from one mind to another through repeated action’. The cultural information that starts a meme may be valuable but this value may be lessened through repeated transmission.

I’m about to list some common leadership memes. Each meme has a core concept that is valuable. But their repeated transmission has forgotten this core concept. In extreme cases, repeated sharing changes them until they oppose their initial meaning. Here’s my top-3 leadership memes :)

1. #agileatscale

I’m going to stick my neck out and say that, for me, working with agility means two things. One: focus on outcomes over outputs. Two: release stuff early and often to check you’re getting the outcomes you want. There’s more to the agile manifesto than my reductive summary. Let’s assume that my summary leaves gaps. The point is that working with agility is based on simplicity. And simplicity is hard.

‘Agile at scale’ has emerged as a concept in the last few years. At its heart, it’s a great concept. It implies they following: ‘OK folks. Our product teams have focused on outcomes for users for a few years now. It’s improved the value of our products and services. Let’s do the same thing with our management teams. And let’s all have a common understanding of the value of our products so we’re aiming towards the same goal.’ Simple principles, hard to achieve.

Sometimes these principles are missed. ‘Agile at scale’ becomes ‘find a framework to link our product teams’. A framework, like Large-Scale Scrum (‘LeSS’) or the Scaled Agile Framework (‘SAFe’), is lifted and shifted onto an organisation. But the organisation doesn’t change any of its fundamental management structures. The framework becomes an add-on to prop-up an old, hierarchical organisation. I’ve worked for a large enterprise that adopted scrum of scrums. The organisation lacked a functional value proposition. There was no transformation of the portfolio or management team. The product teams had disparate goals and users. They weren’t all suited to scrum. The experiment failed and was quietly dropped after a few months. I’ve shared this experience with a few folks over the years. Periodically I receive a message saying something like, ‘my leadership team is about to adopt Less/Safe/etc. It’s going to be a car crash. How do I help them to stop before it’s too late?’. The struggle is real.

This isn’t a dig at either of those frameworks. They can be great. But they’re component of an organisation’s designs. Not the design itself. Working with agility means focusing on outcomes over outputs. It also means releasing stuff early and often to check you’re getting the outcomes you want. If every level of your organisation is doing this then you’re working with agility at scale.

Useful reading

2. #digitaltransformation

Be honest. Do you really know what you mean when you tell people that you ‘work in digital?’ And do you think anyone else understands what it means? Be honest. Think of those glazed eyes at in the pub, at parties and family gatherings. The opaque nature of the word ‘digital’ was recently criticised by UK Government’s Science and Technology Select Committee’s Digital Government inquiry. Their report concluded that the open-ended definition of “digital” made it difficult to assess progress made by the digital agenda.

So wtf does ‘digital’ mean? Harriett Green and Myra Hunt, Defra’s joint Chief Digital Officers, restated what ‘digital’ was intended to mean. Their post what we mean by “digital” returned to source and quoted Tom Loosemore’s original definition:

“Digital: Applying the culture, practices, processes & technologies of the Internet-era to respond to people’s raised expectations.”

Harriett and Myra highlight an important aspect of this definition of digital:

“The first 3 of those are about how we do things. About the ways that people work.”

Technology is the smallest aspect of ‘digital’. We should call ourselves technology teams if our focus is purely technology. We earn the name ‘digital’ when we also improve practices, processes, and our culture. Tom Loosemore’s definition of ‘digital’ summarises research into effective organisational change. I’ve supported digital transformation of the charity sector. Research like The New Reality by Julie Dodd helped me understand that organisational change is complex. Improving an organisation requires investment in people, processes, tools (including technology), and mindset.

‘Digital transformation’ seems to mean a mission and a method. The mission is probably improving the relationship between users and an organisation. The method is probably improvement of people, processes, tools, and mindset. Technology is one component of digital transformation.

3. #deliveryisthestrategy

‘Delivery is the strategy’ was the rallying call for digital transformation in government. The truth is that ‘delivery is the strategy’ is a tactic. It’s used at the beginning of digital transformation. It’s an effective way to build a host organisation’s emotional confidence in a new way of working. This is critical for the first 1-2 years of digital transformation. Growing confidence through tangible software generates new opportunities. This builds a pipeline of work.

This approach builds up a lot of stuff that needs done. And the goal shifts from simply building it, to demonstrating its value. We have to demonstrate return on investment, not just demo software. It’s not uncommon to find ourselves with too much work in progress. And less return on investment than planned. And let’s not mention the headache of supporting and maintaining live software.

‘Delivery [of stuff] is the strategy’ can be a useful tactic for promoting growth of a new digital team. Refining it to become ‘delivery [of outcomes] is the strategy’ is necessary after a couple of years.

Leadership 3.0: Complexity

All organisations are networks and modern leadership is about people and their relationships. This means that we need to view our complex organisations like living organisms. The Lean Enterprise poses the following question:

‘How do we help people within our organisation to make good decisions (i.e. to act in the best interests of our organisation) given that they can never have sufficient information and context to understand the full consequences of their decisions, and given that events often overtake our plans?”.

The answer is that we need to replace leadership based in old hierarchies. Instead we need leadership that embraces the complexity of our organisations. This is often described as systems thinking. Jurgen Appelo takes this a step further and describes this as complex systems theory. Systems thinking being is just one way of trying to understand complex systems. Other techniques highlighted by Jurgen include system dynamics, social complexity, and complexity thinking.

I’ve been re-training myself to be as interested in my complex organisation as I am in my products. I’ve only scratched the surface of complex systems theory. But it’s already helped me on the road to becoming a better leader. Improving my understanding of complex systems theory is one of my main learning and development objectives in 2019-20.

Mission command

Mission command is the framework for actually leading within a complex organisation. Mission command allows leadership in situations where leaders can never have total information. And don’t have the capacity to make all decisions for their organisation. Organisations that exercise leadership through mission command build strong teams with mutual trust. They set missions with clear intent, creating a shared understanding. They encourage disciplined initiative. This allows people and teams to respond to change and to make informed decisions.

Mission command contrasts with command and control. Command and control can work when you have high confidence in the problem you’re solving and high confidence in your solution. It requires strong product/market fit and negligible changes in conditions. I have seen it work for short amounts of time in small organisations but this is rare.

Mission command was developed in the military. I’ve looked to the insights of military professionals to help me better understand it. I particularly enjoyed ‘Five reflections on building a mission command culture’ part 1 and part 2, which shared 5 principles needed for mission command to work:

  1. make sure you have a vision
  2. overcommunicate clarity, at least 2 levels down
  3. delegate until you feel uncomfortable and then delegate some more
  4. to encourage hones views, start by asking the most junior opinion and then work your way up the group
  5. treat other teams as if they are part of your team.

The ‘agile at scale’ meme can be countered by development of a mission command culture. Mission command gives a general approach to working with agility at scale. It does this without imposing a detailed methodology like LeSS or SAFe. Lean Enterprise by Barry O’Reilly et al is a great book to read on this topic. It explains what mission command looks like in a large enterprise. I’ve directly implemented several of its suggestions in my day job. Other concepts have been explored as part of my professional development.

Leadership dimensions

Let’s pause. This is a lot, right? We’re still working on general leadership. We haven’t even got to the specifics of product leadership. How do we keep all of this in mind in a practical way, day to day?

Let’s return to Georg, the coach I worked with during 2017. Georg developed a model to help balance the many dimensions of leadership. He developed it during the year we worked together. This meant that I got to use it and feedback on early versions of it. I’ve found it helpful over the last few years. Georg finalised and published his mode in 2018, you can see it in this post. I’ve taken the model and tweaked it to fit my needs. It’s helped me to think of five dimensions to leadership that I need to balance at all times:

1. My self

I am not my job. My work is not my life. My partner, my family, my friends, my interests and my hobbies are the main focus of my life. My job and the mission of my organisation (my work life) are important to me. But my partner, my family, my friends, my interests and my hobbies (my real life) are more important to me. It’s possible to carry a lot as a leader. Stress can build up. We can burn out. Our mental health can suffer. I’ve found it helpful to train myself to realise that work life is less important than real life.

Taking breaks from work to rest my brain is important. Making time to focus on my partner, friends and family in my real life has the side benefit of making me much more effective when I’m at work. This article in the Harvard Business Review by Kandi Wiens explores these concepts.

2. People

Our organisation are complex systems of people. People are the most important part of most organisations we’ll work for. People are at the heart of transforming how we build and run our products. Mike Bracken attributed the early successes of the Government Digital Service to bringing the right people into government. In an article from 2016, Mike says:

“we hired insanely talented internet-era technologists and gave them a chance to change government, and the great thing about them is they move at such pace. They move so quickly that they can deliver in the time it takes to have the meeting to discuss whether to do the thing in the first place. And they did, time and again.”

I find that lots of product leaders get into leadership through this dimension. We’re asked to manage a couple of product managers. Then a few. Then one day we’re responsible for all the recruitment and performance management for our profession. ‘People’ is often the aspect of leadership that we’re most comfortable with.

I’ve found two things to be particularly useful in developing my leadership skills in relation to people:

  • Building Successful Communities of Practice by Emily Webber has helped me to design a product management profession that supports and develops 50 product managers across the UK. I’ve been using the book since it was published and hired Emily to work with me and my profession to design our community of practice.
  • Performance Coaching is the skill that I use most often in my professional life. I’m a trained, non-directive performance coach. I assume that the head that holds a problem often holds the solution. I help people by listening to them, and asking non-directive questions to help them find their solution. It’s sad how few occasions we get to speak and be genuinely listened to, but amazing how effective it can be for helping us to figure something out. I highly recommend both being coached and learning how to coach.

3. Organisational improvement

It’s important for leaders to commit to improving their organisation. Leaders must continuously work to simplify processes and business complexity, to increase the effectiveness, autonomy and capabilities of teams. We need to be as interested in improving our organisation as we are in our products. We need to get over the urge to use the phrase ‘the business’. We can’t get away with calling colleagues and teams in the same organisation ‘the business’. We should refer to them as ‘colleagues’ and recognise that they’re in our organisation. Not ‘the business’.

At the same time, there’s a limit to how much we can do. I’ve burned myself out a couple of times trying to improve an organisation on my own. John Cutlefish has written a post about the perils of seeing lots of problems in your organisation and trying to solve them all. Government, for example, is too big to be saved by one person. I’ve learned one thing the hard way. As long as I’m always focused one improving one aspect of my organisation then I’m doing my job. I’ve stopped starting lots of things and switched to finishing things. Doing one thing at a time is the best way to see something through to a genuine result. I’ve learned to focus on finishing over starting.

I’ve been using a cycle of organisational improvement for the last few years, known as the improvement kata and popularised by Toyota. The four steps are:

Planning:

  • Understand the direction of change, often derived from the vision set by the leadership (which should be inspiring and potentially unobtainable in practice).
  • Grasp the current condition. Understand and benchmark the current condition
  • Establish the target condition. Identify the aspect of the organisation being addressed, the date by which you want to reach the target condition, and pass/fail criteria by which to judge success.

Execution:

  • Iterate towards the target condition using a plan-do-check-act cycle, series of experiments to achieve (trust people to run experiments and react quickly, not plan all action in advance).

4. Time

This is interesting. I used to take this to mean ‘we all have the same time in the day’, and so we need to prioritise our time. This is true: we do need to prioritise our time. The Design Sprint by Jake Knapp is about the importance of prioritising time. On the surface, it’s a book about a particular method of kicking-off work by have an intensely-planned and organised week of activity. Look a little deeper, and it’s about the general need to design our time as well as we design our products. I heard Jake speak at the 2017 London Mind the Product Conference. He said that the general theme of the book was the need to recognise the value of our time. We have rigorous sprints to plan our work. Then undermine them with unprioritised meetings. We justify all the work in a backlog. Then treat our time as infinite and agree to all sorts of time-sucks without question. The takeaway: design our time as well as we design our products.

I’ve also come to realise that things take time. Sometimes the key to success is leaving enough time. Positive change in a complex organisation often takes at least 6-months. It’s often closer to 1-2 years. A new team takes weeks, sometimes months, to start working well. That’s if it’s a genuinely co-located, multidisciplinary team. Patience and persistence and are the crucial and overlooked ingredients for success. Good things often take time.

5. Value

This is the ultimate test of our leadership. Are our products and services valuable for our users? Is that value increasing over time because of our leadership? Everything we do should be geared towards this dimension of leadership. Value is the most critical aspect of working with agility. It’s the focus of the first of the principles behind the Agile Manifesto:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

However.

Working with agility prioritises values but doesn’t know how to define value. The Agile Manifesto gives us nothing to help figure out what value is. Subsequent frameworks like Scrum also neglect to help us figure out what value is. Most guides assume that ‘value’ is figured out somewhere else by ‘the business’. In reality, ‘the business’ is often waiting for delivery teams to define value. So we we’re all delivering ‘stuff’ early and often without an honest sense of whether it’s truly valuable. This can feed the #deliveryisthestrategy meme.

We can switch from delivering ‘stuff’ to delivering valuable outcomes. We need to define the value proposition for our organisation. We need to define the value of the service(s) we offer. We need to set missions that measure improvement to this value. Sounds a lot like product management, right? Yes it does. Product leadership is product management put to work in a management team. Managing value is the specialism of product managers. And so this leadership dimension is where product leadership comes to life. Product leaders are uniquely placed to shape this leadership dimension for their organisation. Our specialist skill is to take the insights of multiple, specialist perspectives and to find value in the sweet spot where they align. We learn this as product managers within product teams. Our challenge and opportunity as product leaders is to do the same within a management team.

I’ve shared my personal definition of ‘general’ leadership in chapter 1:

  • I’m working in a large, complex organisation so am focussing on this context
  • Leaders must be capable of understanding complex systems
  • Leaders must help people in their organisation to make good decisions in conditions where they can never have sufficient information and context to understand the full consequences of their decisions, and given that events often overtake plans
  • Leaders can achieve this through mission command. Building strong teams with mutual trust. Setting outcome-driven missions with clear intent, and creating a shared understanding of missions. Promoting disciplined initiative. Allowing people and teams to respond to change and to make informed decisions as needed
  • Leadership consists of five dimensions: 1. Ourself; 2. People; 3. Organisational improvement; 4. Time; 5. Value
  • Product leaders are uniquely placed within their organisation to lead on value.

In chapter 2 I’ll share my emerging thinking about the specifics of product leadership:

  • Product leadership is product management applied within a management team
  • Differences between product teams and management teams
  • Adapting product management skills learned in product teams so that they work in management teams
  • Value at an organisational level.

Chapter 2: Product leadership

Product managers often ask me a question: ‘Do you mainly manage people now you’re a head of product? Don’t you miss being hands-on?’ My answer is ‘Yes, I mainly manage people now. That’s what I did as a product manager too. I didn’t build the product or design the product. I managed other people, bringing the insights of specialists together. That’s what you’re doing too, right?’

Product leaders are anxious to remain ‘hands-on’ in a product team or risk losing their skills. I’ve learned that this is a comfort blanket. Product leaders are simply product managers for a management team. We’re hands-on in our management team. We do everything we used to do in product teams but adapt it to work at a larger scale. A team is a team. We’re taking what worked in a product team and adapting it to work in a leadership team.

Working as a product manager in a product team has given us the skills we need to work as a product manager in a leadership team. Yes, we need to adapt them to a new context. But our specialism remains the same. We take the insights from specialists and find value in the sweet spot where they align. The way we do this remains them same. Building the value proposition for our organisation. Defining the value of the product(s)/service(s) we offer. Setting missions that measure improvement to this value.

What’s the difference between a product team and a management team?

Management teams are interesting. Used to working with co-located, multi-disciplinary team of specialists? Then a management team might not conform to your expectations.

Management teams may be monodisciplinary or at least new to being multidisciplinary. Specialists joining management teams may find that they are joining generalists. Generalist leaders may have responsibility for an entire organisational silo. Along with everything that happens in that organisational silo. This is often known as ‘line management’. Everyone has a single management line that leads into a single, generalist leader. This is the ‘old hierarchy’ that Jurgen Appelo referred to as management 1.0. Specialists joining leadership teams represents a move to matrix management. Management becomes a collaborative effort. Divisions of the organisation focused on what needs to be achieved work with professions focused on specialist how to achieve it. Divisions of the organisation are narrow and deep. Professions are broad and shallow. These two perspectives create a useful tension that keep each other honest. The ‘truth’ lies somewhere between the two perspectives. Product teams have understood the value of multidisciplinary team members for years. Lizzie Bruce has written a helpful post about why multidisciplinary teams are good. The healthcare sector has conducted great research on the value of multidisciplinary teams (including their effect on breast cancer survival). It’s exciting to see management teams taking a similar approach.

Management teams may be dispersed. Probably across multiple areas of a building. Possibly across a coutntry. Maybe across the world. In relation to co-located product teams, they may spend little time together. Maybe once a fortnight (or less). They may spend even less time together in the real world. It can take management teams significantly longer than co-located product teams to become high-performing. Trust is the bedrock of a high-performing team. Trust takes time, and is accelerated by spending time together in real life. Trust builds safety. Feeling safe makes us more willing to be vulnerable. More willing to constructively challenge our team members. And more willing to accept feedback. Product leaders joining management teams should look for opportunities to build trust. Guidance on improving performance of product teams is equally useful in improving the performance of management teams. A couple of recommendations include:

  • The Five Dysfuntions of a Team by Patrick Lencioni talks about the importance of trust as the bedrock for high-performing teams. This book is not without its critics who point out that it’s not really based on research. It’s more observations and assumptions that’re tied together. Read it with a critical mind, but there’s some useful stuff in there.
  • The Five Keys to a Successful Google Team by Julia Rozovsky is more recent and more research based, albeit within the constraints of Google as an organisation. Psychological safety has been around as a concept for a while but this post from 2015 has helped to popularise it (as often happens when Google writes about something). This post is a good, simple set of principles for any management team to aspire to.

Finally, what’s the similar between management teams and product teams? Passion.

Grumbling about management teams when in a product team can become a habit. But its important to have empathy, trust, and respect. The phrase ‘hippo’ was used in the product management profession for a few years. An acronym to describe the ‘highest paid person’s opinion’. The implication was that we shouldn’t be solely driven by hippos. This was a reminder to listen to the perspectives of others too. This became a meme that encouraged a culture of devaluing the insights of leaders.

Management teams are full of people who’re passionate about your organisation’s mission. They’re probably operating under the most challenging conditions in the organisation. They have to convince colleagues that ‘digital’ isn’t a hipster fad. Management teams often contain the longest-serving members of our organisation. Here we find some of the deepest insights into what will and won’t work in our organisation. As product leaders we must remember that we have become hippos. It’s important to remember that hippos are people too. The way that we speak about our management teams will set the tone for how the rest of our profession think of them. We have an opportunity to build empathy between management and product teams.

I was freaked-out the first time I was referred to as a ‘stakeholder’ by a product team. Eventually I realised I could improve relations between product teams and management teams. It’s important to move beyond ‘stakeholder management’ (i.e. product team tries to make managers happy so they’re left alone). We need to focus on collaboration (i.e. I have unique knowledge and influence that can help them). Melissa Perri has explored this in her post what everyone gets wrong about stakeholders.

Adapting the skills you’ve learned in product teams to fit management teams

A management team is fundamentally just another team. Management teams and product teams have some superficial differences. Fundamentally, they are the same. The skills we honed as a product manager in a product team are valuable in management teams with just a few tweaks. Here are some examples.

Product strategy (how your organisation achieves its business goals) remains valuable. As a product leader you’re creating strategy for a division of your organisation, or your whole organisation. But you’ll still use the same approaches as when you were in a product team. You’ll use a value proposition to define the overall value of an organisation. You’ll use a business model to optimise costs and improve value at an organisational level. You’ll use a vision to describe your organisation’s future state. You’ll use a roadmap to describe how your organisation gets from today (as expressed by your business model) to the future (as expressed by your vision). Same tools, larger scale.

Product management tactics (how you break the strategy down into SMART goals for a team) also remains valuable. User stories are only one way for a product manager to set SMART goals for their team. I took Roman Pichler’s Scrum Product Owner training many years ago and he shared a story. His colleague came up with the ‘user story’ as a way to help one organisation set SMART goals. Since then it’s become another meme that’s lost its orginal context. It was never intended to be the only way to set SMART goal. Just one technique amongst many. This reflection is useful for the product leader. We can set SMART goals in management teams if we think about new ways of expressing why we should do something. I’ve been using an improvement opportunity tempalte to help set SMART goals at scale. Specifically to help introduce rigour and accountability to organisational improvement. Organisational improvement is often invisible and often just happens. This makes prioritisation, accountability, and learning difficult. I’ve started using the following way of expressing work to improve mmy organisation as a SMART goal, taken from Lean Enterprise:

Section Description
Background Capture the critical information to understand the extent and importance of the problem. Tying the background to the goal statement reduces waste by limiting opportunities to focus on the wrong areas.
Current condition and problems statement This is the problem the business stakeholder wants to address, in simple understandable terms and not as a lack-of-solution statement. For example, avoid statements like ‘Our problem is we need a Case Management System.’
Goal statement How will we know that our efforts were successful at the end of implementation? Ideally we will need one metric for success. For example, ‘Our goal is to reduce system failures compared to the previous test results of 22 major issues; our target is to reduce this by 20%.’
Root-cause analysis Detail the hypothesis and assumptions, or a set of experiments performed to test for cause and effect.
Countermeasures List the steps of an experiment to test the hypothesis.
Check/confirmation effect Define a method for assessing if the countermeasures have had an effect.
Follow-up actions and report Identify further steps and share what you have learned with your team or organisation.

I’m not suggesting that we now use this way of setting SMART goals for all organisational. It’s intended to show that we can set SMART goals in all sorts of contexts if we learn tricks beyond user stories.

Prioritisation

Barry Overeem suggested a great way of balancing all of the work needed to optimise a mature product. Barry’s backlog prioritisation quadrant reminds us that all mature products need:

Improved support New features
Reduction of tech debt Innovation

All four classes of work are required throughout the lifetime of a product if it’s value is to be improved. If we’re working in 3-month blocks (for example) then some work will need to happen in all of these areas each quarter. Otherwise our product will deteriorate, and eventually break.

We can take this and apply it at scale. Here’s a portfolio prioritisation quadrant.

Improved client/user relationships Improve products
Reduction of organisational dysfunction Organisational innovation

All of these activities need to happen every quarter. The challenge is to prioritise the amount of our time and money we spend on each. And to review and change this balance every quarter as conditions change.

And lots more

I’ve written a handbook for product managers. It summarises the core concepts, skills, and principles of product management. It contains the most common topics of my 1:1s with product managers over the last few years. It has a product leadership section but it is weak. A couple of years ago I I didn’t really have Lead Product Managers. And the discussion around Senior Product Managers was simply ‘how many products can we get them to manager?’ We’ve moved on since then. Senior Product Managers can be seen as group product managers. They’re responsible for the overall value proposition for a group of products. I now realise that product leadership takes the skills we learned as product managers and adapting them to work in management teams. Most of the product management skills in the handbook for product managers can be adapted to work at scale.

Value at an organisational level

Lots of teams and organisations struggle to define what makes them valuable. More accurately, they struggle to be honest with themselves. Their value proposition describes what they think they do or what they’d like to do. They need help to desribe what they really do, and what their users genuinely value. This was a key theme of the Mind the Product 2018 conference in London. Janice Fraser’s talk about uncovering the truth was particularly insightful.

Product leaders must uncover the truth about what makes their organisations valuable. It’s an essential foundation for good product strategy. The book that has most helped me to start uncovering the value of my organisation is The Art of Business Value by Mark Scwartz. It’s the most thorough yet concise description of value, cross-sector, that I’ve encountered.

I’ve done a lot of thinking about value in my context because it’s critical to my role. I’ve shared my current thinking in a series of posts starting here.

Afterword

That is my product leadership journey to date. This post is not a grand statement on all product leadership. It is an honest summary of my own approach to product leadership. This post marks the end of the beginning of my development as a product leader. I’ve learned enough to realise that I have a lot more to learn. So I’m sharing this to spark a conversation (aka making things open makes things better).

My approach to product leadership is influenced by what I’ve learned from my other people. I’m going to test this post out with many of those people, and no doubt improve it based on those tests. I lead a profession of 50+ product managers and our 1:1s are a continual source of learning and refinement. The Heads of Product in government meet at least once every couple of months. I have a group of product management friends built-up over the years who I meet up with for dinner every few months. Mind the Product started a spin-off meetup for product leaders in April 2017. It’s become a safe space for product leaders from all types of organisations to talk honestly. Many people make time to write down their thoughts and share the on the internet, for free, in order to help others. The people I’ve referenced in this post are just the tup of the iceber. Product management is stepping out from behind technology into management teams. Product Leadership is new and sketchy. Which is great, because it’s up to all of us to determine what it becomes.