‘Ten year retros’ appeared in my Twitter feed in Autumn 2019. I found them interesting and appreciated their honesty. I began sketching my own but had too much to say and got stuck. I had other things going on in real life, figured my time was more valuable elsewhere, and put it to one side. Then 2020 hit and half way through I decided to have another go. I gave myself 6 months. Didn’t rush. And have learned things I’d never thought of before. Here are fifteen things I found most interesting, shared in the hope that one or two of them are interesting to you too.

I’m using retrospective to mean the inspection of my professional life over the last decade, looking for assumptions that led me astray and changes I can make to improve the next decade.

The fifteen things are (in case you want to jump to the ones of interest):

Product managment remains misunderstood
Product managers don’t need Computer Science degrees
Don’t fetishise commercial product management
There’s more to strategy than roadmaps
Head of Product: opposite of what I expected
I’ve taken Discovery for granted
Models can liberate thought
There’s a world beyond product management
The Agile Manifesto is about behaviours, not software
There’s more to life than working with agility
Non-directive coaching is most valuable thing I’ve learned
Words matter
I like to work with other people as part of an organisation
Good things take time
Focus on finishing over starting.

1. Product management remains misunderstood

Improvement

Clearly and simply define product management. Then update the Wikipedia entry for product management.

Background

I started the decade thinking everyone else had product management figured out. I ended the decade thinking that product management is all things to all people.

Have you seen the Wikipedia entry for product management? It’s terrible but may be the first thing seen by people wanting to learn more about the profession. There are a few definitions around but they’re often context specific (Californian technology startups dominates) or misunderstand the role (rebadging project management, team management, or technology management). Conflating narrow frameworks (like the Product Owner role in Scrum) with the profession is also common. In the next decade I’d like to feel confident enough in my ability to simply and clearly explain product management that I could update our Wikipedia entry.

Progress

I’ve made a start. I think that we can be pitched as the people responsible for improving outcomes for our users (maybe outcomes manager or value manager would be a better way to describe ourselves?). Product management is about improving the value of products and services for their users and their organisation. I’ve had a crack at describing product management in something approaching plain English.

2. Product managers don’t need Computer Science degrees

Improvement

Advocate for a broad range of routes into product management.

Background

Beginning of the decade. I was self-conscious that I didn’t have a background as a developer and I didn’t have a Computer Science degree. The same common concern has been whispered to me in private by many other folks. I’ve come to realise it’s not a problem. In fact, it’s a good thing. You want your developer to have a background in development. Product managers need to understand multiple specialist perspectives in order to find value in the sweet spot where they align. One of those perspectives is sometimes development but most of them aren’t. The main thing at work here is understanding people and understanding how to align people. That doesn’t require a Computer Science degree. You don’t need one to be a product manager and I don’t look for one when recruiting product managers.

On a personal level, I have an MA in Critical Theory. I never expected it to have practical applications, if I’m honest. But critical theory helps me to look at human systems and uncover their underlying power structures. Turns out this is a useful skill when finding social problems to try and help solve.

Progress

Mainly passive. I’ve never used a Computer Science degree as a reason to recruit a product manager. I judge openly and fairly based on the skills and level of skill listed in the job advertisement. But based on lack of confidence around not having a development or Computer Science background, I can take a more active approach. I’ve made a start in a recent episode of my newsletter, and have started thinking about explicit product management principles, behaviours, and skills that make this much clearer. A lot more to do on this one.

3. Don’t fetishise commercial product management

Improvement

Amplify product management that puts people before profit.

Background

I’ve been guilty of fetishising the private sector. When I started as a product manager I was self-conscious that I hadn’t worked for a Californian tech giant. The most popular product management guidance is designed for the private sector. I’m good-lazy. If something exists, I don’t want to reinvent the wheel. So when developing as a product manager I started from this private sector-focused guidance. And it’s great. But after working in that sector and seeing behind the scenes in a lot of these organisations I realised that they don’t have it all figured out. It’s no longer true that they are creating better products and services than other sectors. I’ve learned to be constructively critical of some of this guidance. If a company isn’t profitable, relies on investment, and burns ten-times more money per month than you: it’s not that impressive that they have a slightly slicker product than you. The point of this is not to trash commercial organisations. Most of them are ace. And they often share their learning generously. The point of this is that we in government, Local Authorities, charities, non-profits, social enterprises, and NGOs are doing just as interesting work, often with a more varied range of users and in more challenging conditions. We don’t need to fetishise the private sector. They’re just people doing work like us, with insights no more or less valuable than us.

Progress

Early days. I’ve done some ad hoc, one on one conversations and helped some people to make the jump from commercial sector to non-profit sector. I’ve recently started a newsletter called Good Product Management to see if I can usefully build a platform to amplify product managers who put people before profit. But, as with a few on this list, a lot more to do.

4. There’s more to strategy than roadmaps

Improvement

Talk about product strategy in its broadest sense and downplay the significance of the roadmap.

Background

Product roadmaps are overloaded with significance and are a source of uncertainty among product managers. It’s the most common topic to come-up in communities of practice, coaching, and mentoring. And it’s often code for something else. Asking for the product roadmap often means ‘I’d like to know what your product strategy is’. Product strategy is built from lots of things, roadmaps are just one of them.

Progress

I reckon I’ve done as much as I can on roadmaps themselves, culminating in this post for Mind the Product and this overview on my own blog. I need to start talking about product strategy more generally and show roadmaps to be just small part of it. Made a start in a recent episode of my newsletter.

5. Head of Product: Opposite of what I expected

Improvement

Dedicate as much time to developing your operational skills and organisational skills as you do on your product strategy skills.

Background

I started as Head of Product for my organisation in 2016. I’m still excited and privileged to have the role. Today we’re a profession of 60+ people in a business unit of 1,000+ people serving the whole of England and an internal workforce of 80,000+ colleagues. Big challenges, amazing job satisfaction.

It’s also been the exact opposite of what I expected. My focus for the first year was the operations of the profession. Second year, organisational improvement was added on (we had a large merger). Third year was seeing lots of work pay off and the profession reach maturity. It’s at this point that I start significant work on thinking about value and product strategy across the organisation. And notice I say ‘begin’, rather than ‘have sorted’. My expectation of Head of Product/Director of Product/Chief Product Officer had always been that it was focused on value and strategy alone. But I was (kind of) the first Head of Product at my organisation and what everyone needed initially was an operational Head of Product. Over the years, each operational activity and organisational improvement has cleared a little more space for strategy. And most importantly, each awesome person working with me in the profession becomes a leader in their own right. All of this adds up to me making the space and earning the privilege to start doing more strategic work.

Progress

I started this improvement in 2017, continuing in 2018, and sharing it via a post in 2019. I’ve learned and improved since than and need to implement more in 2021, alongside looking for gaps and undertaking further development.

6. I’ve taken Discovery for granted

Improvement

Regain enthusiasm for helping those in Discovery.

Background

This began life as a ‘here are all the common problems I see with Discovery’ piece. Then I came back to it and thought ‘who am I helping by complaining about the common problems I see with Discovery?’. Answer: myself. I’m making myself feel better. I deleted the snarky version. I realised that I’m the problem. I’ve taken Discovery for granted.

I did my first ‘proper’ Discovery back in 2007. The Cabinet Office began publicising ‘customer insights’ back in 2006, paving the way for the Government Digital Service. The new idea was to research your customers (we now call them users) and collect insights in a customer journey map. I lapped this up and put it to work immediately. At the time I led support for trainee teachers with special educational needs when taking their skills tests. I had budget and permission to develop new guidance for them. But gave this customer research thing a try. The average number of attempts for people with special educational needs to pass their skills tests was in the range of 3- 5 attempts (from memory). The assumptions were that they needed (i) better adaptations or (ii) better guidance and training. A couple of weeks research suggested otherwise. Pulling this together in a customer journey map, trainee teachers were taking the standard tests and failing them 2-3 times before they were finally told that they were entitled to adaptations. Once they had the adapted tests they were entitled to, they passed within 1-2 attempts. This matched the overall average. The intervention we made was to help teacher training providers, tutors, and testing centres publicise these adaptations. We improved the visibility on our corporate website too. The outcome was to reduce the average number of attempts from 3-5, to 1-2. This saved a huge amount of time and stress for trainee teachers. It had the added benefit of increasing testing capacity of the testing. It was much cheaper than new software or guidance. And much more effective. I was excited by a world where this research into customers was the way we all worked.

Jump to 2020 and this is how a lot of work now begins. Yes there are problems. Yes it’s imperfect. But it’s a huge, huge improvement. If 2007 me knew that I’d be funded to introduce Discovery in the social enterprise and charity sector, lead a cross-government retrospective of Discovery, and eventually lead Discovery for a government department . . . I wouldn’t believe it. I’m guilty of taking this for granted and need to remind myself how awesome this is.

Progress

This retro is my progress to date. I hadn’t realised that I was taking Discovery for granted until I started writing. Awareness is curative. I’m returning to work with a renewed enthusiasm for Discovery. I think something simple like regular ‘Discovery: Ask Me Anything’ sessions could be a good thing to do. One of my colleagues has recently been doing support and training in this area so I can learn from them what’s needed and what works.

7. Models can liberate thought

Improvement

Clearly and consistently use, test, share, and improve models that help with product strategy.

Background

It’s easy to get lost in product management. Overloaded with opportunities and decisions? It’s easy to hide in feature prioritising and resolving team issues. The business model canvas was the first model that helped me to get my head back in the strategic bits of the role, learning enough to make tough decisions for the improvement of the product. I first wrote about it in a post from 2013. I’d probably explain it differently in 2020 but the post is linked to from GOV.UK so it still gets traffic. Since then I’ve found many more models that help me when I feel stuck or overwhelmed. But I’ve not kept this list up to date, used the models consistently, or put enough effort into testing them, sharing them, and improving them.

Progress

I created an internal product management handbook in 2016 and shared it in 2017. A few organisations asked if they could use it so I published an open version in 2018. However this is out of date, doesn’t include worked examples, and misses models I’ve found or developed since then. It’s also not as clear or well promoted as something like Liberating Structures from over in the coaching bit of the world.

8. There’s a world beyond product management

Improvement

Look outwards and learn from other specialist roles and elsewhere in the Civil Service. Spend as much time learning from other professions and contexts as I do shaping my own profession.

Background

I started out the decade figuring out product management for myself. Then I moved onto figuring out what it means for my profession in my organisation. Alongside this, working with my peers to figure out what it looks like in government more generally. This was all necessary but hugely introspective. Around 2018, me and the fellow ‘Heads of’ at my organisation realised that we’d spent a long time figuring out how we each work on our own terms but not enough time figuring out how we’d worked together. The same realisation hit with my fellow Heads of Product across government. We were always talking about ourselves and to ourselves, and we’d got as much from that as we could. We needed to learn from each other.

In 2019 it became increasingly clear that we need to step outside of the ‘digital bubble’ entirely if we’re going to radically improve public services. The Civil Service is vast, full of great people doing amazing things. ‘Digital’ is just a sliver of this. We’ve maybe been guilty of thinking we can go it alone but the truth is that we can’t.

Progress

A fair amount made with respect to other professions in the last couple of years. I learned a lot about broader Civil Service 2005-2010 because that’s where I worked. But I left for five years and it’s been relatively limited since then.

9. The Agile Manifesto is about behaviours, not software

Improvement

Join up the organisation to focus on users, worry less about ‘being agile’. Clearly describe the behaviours that help my organisation to join up and focus on users.

Background

I’ve come to the realisation that the Manifesto for Agile Software Development is not about software. It’s really a manifesto for behaviours that allow us to cross boundaries to focus on the needs of users. I see a parallel in the notion of soft skills by the US Army. Soft skills describe the social skills needed to lead groups, beyond those specialist skills needed to operate machinery. The Agile Manifesto and soft skills are both ways of describing general behaviours that help us in our relationship with our social environment.

At its best ‘working with agility’ nudges us towards these positive behaviours that cross boundaries and help us to work together to serve our users. At its worse, Agile is a cult that erects more boundaries within an organisation and leads to a new tribe. So I think that clearly describing our ultimate goal (working together across silos to help users). And freeing ourselves up to describe the behaviours that help us to do this within our own context. Will help us to achieve the intent behind the Agile Manifesto without using it as an excuse to exclude people.

Progress

This retro is my progress to date. I’d never thought this before. Now it seems obvious to me. I think this is something that’d benefit from a blog post in its own right, to share with folks to see what they reckon.

10. There’s more to life than working with agility

Improvement

Match the right delivery conditions with the right opportunities.

Background

Something that’s been bubbling up for the last few years is a downside to the popularity of agile product teams. Default position has been to chuck an agile product team at all opportunities. We’re a victim of our own success. There are teams out there really struggling to figure out how to work on the thing they’ve been given in the way that they know how to work. This got a little clearer for me in the first half of 2020 when I worked with the Service Owner profession. They’re often responsible for some or all of a value chain in which in-house software is just a small bit. There’s also outsourced software, commodity software, hardware, and physical infrastructure.

Progress

I was figuring out what to do next when I saw this tweet from Simon Wardley which gives a worked example of what’s been bubbling-up for me for a while. Immediate next thing to do is read this properly, then figure out what to do next. My hunch is that there’s value in creating a value chain for something at work, creating a version 1 of the delivery approach best suited to the different elements of it, then noting the delivery approach we actually have in play.

11. Non-directive Coaching is most valuable thing I’ve learned

There’s no improvement here, I just need to keep on using non-directive coaching and advocating it to others. I was trained as a performance coach in 2008 and it’s been the set of skills of used most often with most value since then. Here’s a post from way back in 2013, the first time that I realised how useful coaching was to me.

12. Words matter

Improvement

Define words that we use a lot without clear and consistent meaning.

Background

I reckon that lots of large organisations have at least five different meanings for the word ‘service’. And that this causes feedback loops that eat time. See also a word like ‘digital’ and a phrase like ‘digital transformation’.

Progress

Made a start at work in 2020 before taking my main chunk of shared parental leave, will pick up again in 2021.

13. I like to work with other people as part of an organisation

There’s no improvement here. It’s just useful to remind myself. I tried working for myself for a year and loved the range of clients, the variety of work, and the day rate. But didn’t enjoy how running my business became the sole focus of my life. I naturally do a lot of professional development around the day job but am free to do a variety of things and setup personal projects. Running my own business, all my time was on the project of developing my brand and developing new clients for myself. There are loads of people who love this. I think I might love this in the future. But at the time it was not good for me.

14. Good things take time

Improvement

Assume that meaningful change in a complex context at a large scale will take years.

Background

Time has always been important to me, professionally. I started out as a project manager in a former life. ‘Time, scope, and cost’ were my holy trinity of constraints. You can fix two of them if you have to, but expect the third to shrink and shrink and shrink.

I learned to apply this to myself. There was too much to do when I became Head of Product and I worked with a coach to improve my performance. They had a leadership model in which time was an important dimension. Time is used as a reminder that, “everyone has the same amount of time each day, 1440 minutes. That’s it. Time is a constant, everything else flows around, and through it.” This is a good nudge to design our time as well as we design our products, using it in the most valuable of ways. And saying ‘no’ when necessary.

There’s another aspect to this. Good things take time. Meaningful change in a complex context at a large scale will take years. There’s no way around this, in my experience. At the beginning of the decade I founded an advocacy service for young fathers, now called Young Dads Collective. The first year was building a viable network of partners around England. Year two was building something valuable. It was year three before we started to have real impact (influencing govt policy, charity policy, local authorities, medical professionals). Skip forward to the second half of the decade and it took me three years to build a community of product managers that was mature enough to run itself and to have strategic influence in both delivery teams and leadership teams. These are two examples amongst many. And both example we’re seeing the beginning of impact, not the end.

I’ve ignored the fact that good things take time. I’ve assumed that ‘this time will be different’, as though enthusiasm alone can change reality. But it’s unhealthy and can start me (and others) off at a pace that is not sustainable for the long haul. The change I can make in the future is to accept that good things take time and accept that ‘this time’ won’t be different.

Progress

Limited, if I’m honest. 2021 will be the first time I’ve explicitly set myself the challenge to do something with this.

15. Focus on finishing over starting

Improvement

Release the value of what I’ve got before doing something new

Background

It’s 2009. I’m working on digital transformation of education before it was known as digital transformation. My boss was great at finding underspend at the end of the financial year and then handing it over to teacher training providers to invest in technology with as few strings attached as possible, trusting that they know what they’re doing. My boss manages to find around £20 million of investment over five years. Then 2009 hits. It’s clear that austerity is on the way and there’s no underspend. We’ve got a fraction of our normal budget. We invest it in learning what has worked over the previous years, evaluating the impact we’ve had, and creating guidance to help providers of teacher training to use technology. This guidance proved to have longer lasting impact than any previous year of heavy investment in technology. We needed to release the value of the technology we’d already funded rather than continuing to provide more and more new stuff. Junp to 2020. I’ve worked pretty solidly for the last decade and blogged about some of the main things I’ve learned. I’m on shared parental leave for most of the year and won’t be blogging about new stuff. I tell product managers not to develop new features until they’ve released the value of their existing ones. Maybe I should practice what I preach and release the value of what I’ve already learned and blogged before I go seeking something shiny and new.

Progress

This retrospective represents a lot of my progress. It might be one of the best professional learning experiences of my last few years. I’ve also published the first season of a newsletter sharing, repackaging and updating previous blog posts and guidance I’ve written.