Scott Colfer's Blog

Movement Creates Clarity: How I Became Someone Who Finishes Writing a Book

2025-10-05T00:00:00+00:00

I’ve written a book called Product in Service: A Manifesto for Pragmatic Product Management. Here’s how that happened.

1. Impulse and Permission

For years I’d been hearing product people struggle with the feeling they’re ‘not doing proper product’. Across the product management profession I led, in coaching sessions, and later inside a consultancy, the same pattern surfaced: smart people, stuck in systems that made pure product management almost impossible. At a meetup of Chief Product Officers in the public sector, we all saw it: multiple unfinished transformations, unclear authority, cultural drift. Everyone recognised the symptoms. But when you’re ‘in house’ it can be hard to share openly and honestly what’s going on in your own organisation. No one could write openly about their own situation. But I wasn’t in-house. I was at a consultancy and free to talk about my past experiences. So I decided to do it while I still could.

2. Discovery and Craft

I’d wanted to write for most of my life but the “great novel” never arrived. At the end of 2023 I almost gave up on this dream. One last spin of the dice, I told myself. I signed up for a short creative writing course at the Faber Academy. It was on “creative nonfiction,” a term I didn’t even know existed. The discovery felt like a click.

I’d been so fixated on fiction that I’d missed what was already in front of me. For years I’d been writing creative nonfiction, just in disguise: frameworks, guidance, playbooks, blog posts, pitches. All of it, really, was story work. The course gave me permission to see that. To write about work as lived experience.

I’d gone in intending to write my memoir, but came out with the seed of Product in Service.

I’d also read too many professional books that said little, slowly. I wanted to apply the precision of fiction: the fewest words for maximum effect. Alice Sheldon, who wrote as James Tiptree Jr., became my quiet mentor. Her story The Screwfly Solution tells the story of the end of the world in a few pages. That compression, that humanity, was what I wanted: a book short enough for a train ride, deep enough to stay with you.

3. Making and Momentum

Anne Lamott’s idea of the “shitty first draft” became my north star. I gave myself permission to make something bad as long as it was real:

Fifty sides. A5.
Two hours writing most weekends from August to November 2024.
No polish, no delays, no excuses.

By December, I had a printed zine-sized draft: thirty copies sent to readers. Four months from idea to artefact. Constraint made it possible.

4. Reflection and Revision

Feedback began arriving before Christmas and kept flowing until February 2025. Voice notes. Annotated photos. Returned copies filled with scribbles. People really read it. They said:

The main point is true, and it’s the first time I’ve heard it said out loud.
It needs more structure and sign-posting.
The “Email to the Universe” is strong and should open the book.

I’d come to similar conclusions myself. It was the perfect mix of affirmation and challenge. After months alone, the book was now in conversation. Readers met it with generosity, and their reflections sharpened mine. It confirmed what was real, and showed what to leave behind.

5. Expansion and False Starts

January brought the first talk on the book, with the Cambridge University Press & Assessment, and from there the ideas began to travel. Each audience became an edit: what landed, what drifted, what drew silence. Speaking turned out to be a form of rewriting. In my day job as Director of Product & Strategy, the concepts in the book began helping clients. In coaching sessions they helped people name what they already felt. Testing the ideas in the wild took everything to the next level.

At the same time, I hit two false starts.

The first was trademarking. My original title was New Wave Product, and I tried to make it official. That led to a minor dispute with an existing trademark holder resolved amicably, but not worth the cost. Hundreds of pounds in fees for something that didn’t actually matter. It was a frustrating detour, but also clarifying: the title no longer fit the book anyway. The more I sat with it, the more I realised the real focus was product management within services. Not some new wave of fashion, but a deeper recognition of context. That insight gave me the final title: Product in Service. What had started as a bureaucratic headache became a moment of clarity.

The second red herring was Squarespace. My plan was to print copies of the finished book, sell and post them myself, and run it all through a neat little Squarespace site with Stripe integration. Except Squarespace was anything but neat. For all the praise it gets, I found it clunky, confusing, and expensive — a maze of templates and dead ends. Compared to my old self-hosted WordPress days, it felt like a regression. So I shut it down. Deleted the site. Cancelled the account. In the end, I went back to simplicity: my own website, hosted on GitHub, fully under my control. A reminder that the best tools are the ones that stay out of the way.

6. Completion and Release

Editing eventually stalled amidst real life. So I booked a solo weekend in late June 2025, cycled to an Airbnb in Dulwich with one goal: finish. I began by handing my second draft to ChatGPT, asking four blunt questions:

What repeats what already exists?
What’s truly new or useful?
Where’s the structure weak?
What patterns have I missed?

This helped focus the final edit. Over two days I worked with ruthless clarity: cutting, reordering, tightening every line for structure, coherence, and freshness. By the end of the weekend, I had it. A finished manuscript. Out of my head, onto the page. That feeling of relief, pride, and completion was the real publication moment. I printed a few copies for final review and sent them to early readers. Their feedback confirmed it: the issues from the shitty first draft were gone. The structure worked, the story flowed, the message landed.

Then I rested. July became a recovery month: space to let the words cool, to get my perspective back.

In August, a colleague mentioned that her husband specialises in self-publishing (see his website here). We had a chat and he kindly walked me through Amazon’s system and it was clear: the easiest, most scalable way to self-publish was right there. So I pivoted. I commissioned a freelancer to format the manuscript for both e-book and paperback. I uploaded to Amazon, and in mid-September the e-book went live. I promoted it through my newsletter (a small, personal launch) and the feedback began to roll in. Within the first week, the e-book hit #1 in the UK Nonprofit and Charity category.That early success built visibility and gathered reviews, the social proof that would carry the paperback.

In early October, I launched the paperback. And almost immediately, it outpaced the digital version. People still love the physical book: the weight, the paper, the mark of having finished something real. It felt like the perfect ending. A small, handmade book that grew through honest feedback, hard reflection, and quiet persistence, and somehow found its readers.

7. Integration and Continuation

It’s still satisfying and surreal to see people read and respond to the book. To see it quoted, reviewed, discussed. Many have taken time to write to me: generous reflections that make the work feel shared.

And there’s a quieter satisfaction: after living with these ideas for so long, they now sit in my head ready to deploy. In meetings, workshops, coaching I can reach for them instantly. The book became a mental framework, a kind of internalised map.

8. Beyond Product in Service

When I finished Product in Service, I wanted to know if it spoke beyond my own corner of the world. So I sent a handful of copies to folks from the commercial world too. I wanted to test how well the book travelled: did its ideas hold up outside the public sector? Could others see themselves in it? One piece of feedback in particular stayed with me. It came from someone working in SaaS, who said:

“There’s a wide belief that SaaS companies are the home of ‘proper product management,’ but in my experience they suffer from many of the things you’ve identified too. Everyone’s trying to emulate the 1% — the Amazons and Netflixes — while the rest of us are dealing with messy realities and unfinished transformations. Your book made sense of that.”

That comment lit something up for me. It confirmed a hunch I’d been carrying for years: the challenges of product management aren’t really sectoral. They’re structural. Most organisations, whether public, private, or nonprofit, are navigating complexity, legacy, and culture at once. The language changes, but the work doesn’t. When I’d joined Mind the Product Leaders meetups, I’d already sensed this. I’d listen to people from fintechs, startups, and big tech, and their stories sounded just like ours in government. Different acronyms, same knots: overlapping cultures, half-finished transformations, competing truths. So hearing it from readers felt like permission. Permission to widen the lens, to speak not just to those in service, but to the 99% trying to make things work in complexity. To take the clarity of Product in Service and let it evolve into something broader. Not a framework, but a way of orienting product within messy organisations. If I write a second book, this is where it will begin.

What I learned About Writing and Self-Publishing a Book

If I were to end with what I learned about writing a book it would be as follows:

1. Constraint is freedom

I learned that scale kills momentum. Fifty sides, A5, two hours at weekends: these weren’t compromises, they were enablers. This container gave me movement. And the act of defining “small enough to finish” turned out to be the first act of authorship.

2. Iteration is orientation

I didn’t know what the book was until I’d written the shitty first draft. Each loop (writing, feedback, talking, revising) was an improvement cycle. I discovered that I couldn’t find clarity then move; I had to move to find clarity.

3. Conversation is editing

Every talk, every reader, every message was a structural note in disguise. I realised that story lives in dialogue, not solitude. That testing ideas in the wild is how you learn what’s actually true.

4. Tools are only useful when they disappear

Trademark bureaucracy, Squarespace tangles: each false start showed that friction hides in systems that promise simplicity. Real progress happens when tools vanish and you’re left with the work.

5. Honesty scales better than hype

The feedback I valued most relaed to authenticity: “this feels true.” Not a single reader mentioned polish or brand; they responded to clarity and honesty. That confirmed my instinct: quiet truth beats loud marketing.

6. The writing of the book teaches the book

By the end, Product in Service wasn’t just a book about pragmatic product management, it modelled it. I prototyped, tested, iterated, and shipped. The process embodied the product philosophy.

7. Completion is a form of integration

Finishing the book didn’t just produce an artefact; it rewired how I think. I now carry the material in my head, readily usable in real conversations. It’s no longer “ideas on a page”; it’s part of my reflexes. The book became muscle memory.

8. The niche is the gateway

By speaking from my lived corner of the world, I found authenticity. The local truth of product in service revealed a bigger patterns.

Using AI Without Losing Yourself

2025-09-12T00:00:00+00:00

Stage 1: False Starts

I first picked up Gen AI about six months ago. At a public sector product meetup, a speaker showed an app they’d built with AI: a simple arrow that always points to the centre of the galaxy. It looked effortless. I wanted to try.

My own experiments were clumsy. I don’t code, and the outputs I got were hobbyist at best. I used ChatGPT to help me create an app to integrate with the Spotify API to build a better podcast search. Nothing I made was particularly useful.

But something else happened: I realised Gen AI didn’t have to be my app-builder. It could be my thinking partner. Where I brought experiences, it brought reflection. Where I had fragments, it helped me see concepts. That shift, from tool to partner, is what stuck.

Stage 2: Building a Mirror

Following my instincts, I tried something different. I didn’t want to plagiarise, and I didn’t want generic outputs. What I did want was to make more of what I’d already written over the years.

So I trained ChatGPT on my own publicly available writing. I asked it to zoom out: to look for themes, patterns, models, tone of voice. Then I asked what became the most powerful question of this whole journey:

“Permission to be honest, play devil’s advocate. What are the strengths and weaknesses in my ideas? What am I saying that just repeats others? And what do I offer that even you, ChatGPT, don’t already contain?”

That’s when something relly interested happened. I wasn’t just experimenting anymore. I was shaping a way of working. Over time it became clear that I was building what I can only describe as an AI constitution: a set of principles baked into my interaction with ChatGPT. It carried my unique perspectives, my ethics, my tone of voice.

Stage 3: From Notes to Guides (and a Book)

With a constitution in place, I started pointing Gen AI at new writing. I had a newsletter with a steady audience, but something nagged at me. Most of what I was publishing felt more like field notes (raw observations from the front line of product in the service sector) than field guides, the kind of structured, actionable guidance that helps others.

So I experimented. With ChatGPT, I studied my most guide-like outputs and noticed a pattern:

A real story — grounded in lived experience.
An abstracted model — the bigger system or principle behind the story.
A practical takeaway — something a reader could use the next day.

That became the structure. I brought raw notes and experiences; ChatGPT helped me find the unique angle, shape them, and make them usable. The result? Three monthly newsletters that doubled subscribers, tripled monthly reads, and, most importantly, sparked real engagement: comments, direct messages, invitations to speak.

I wasn’t outsourcing my thinking. I was sharpening it. I wasn’t getting generic content. I was creating ideas more uniquely my own.

With that confidence, I turned to my ultimate field guide: my book.

The draft was already mine: written, tested in talks, refined through 20+ early readers. But now I wanted to finish. I gave ChatGPT the manuscript and asked the same core questions I’d been refining for months:

Permission to be honest. Play devil’s advocate.
What models and patterns do you see?
What am I saying that’s already out there?
What is unique and valuable?
Where are the strengths and weaknesses in the narrative?

The feedback, layered with early reader comments and my own instincts, gave me what I needed. I took myself to an Airbnb for a weekend and finalised it.

By then, my constitution had grown symbols and shorthand, metaphors that acted as anchors. The most useful? The relationship between Tony Stark and JARVIS in the Marvel films. It isn’t perfect, but it mostly holds.

The Constitution in Practice (Stark ↔ JARVIS)

1. Stark sets the mission.

The human defines the purpose, direction, and ethics.

2. JARVIS scans the system.

AI zooms out, spots patterns, themes, and blind spots.

3. Stark brings instincts.

Judgment, lived experience, and emotional truth stay human.

4. JARVIS sharpens coherence.

AI structures ideas, stress-tests narratives, and keeps tone consistent.

5. Stark acts, JARVIS reflects.

Final responsibility, authorship, and delivery are mine.

6. Together, they amplify.

Not replacement, not plagiarism.
A co-creative loop where judgment × pattern-recognition creates clarity and movement.

Stage 4: Using AI Without Losing Yourself

Looking back, what started as a failed attempt to build an app has become a working practice. I don’t use Gen AI to think for me. I use it to help me think. The constitution I’ve built — part ethics, part tone, part shorthand — keeps me anchored in my own voice.

That’s the key lesson for me so far: AI can expand your practice without erasing your self. The danger isn’t plagiarism or automation. The danger is letting the machine’s voice become yours. My way through has been to bake myself into the process, so that what comes out is not generic, but more recognisably my own.

This field note is an example. The story is mine. The reflections are mine. The structure, the sharpening, the coherence: that’s where ChatGPT plays its part. Writing it this way enacts the very constitution I’ve been building: a loop of experience → reflection → coherence, without losing my own voice.

Use AI. Don’t lose yourself.

5-Year Blueprint for Community of Practice

2025-08-22T00:00:00+00:00

Most blog posts about communities of practice cover the first couple of years. I had the unusual chance to lead one for six (the product management profession at the Ministry of Justice).

That gave me a front-row seat to how a community evolves: fragile beginnings, growing pains, and eventually becoming part of something bigger than itself. I’ve framed it using a leadership arc: Explorer → Builder → Architect.

This post is meant as a blueprint for the first five years of any community of practice. It’s a much shorter version of a post I previously shared, feel free to read that if you want more context.

Stage 1: Explorer – Feeling the Terrain

Story

Back in 2016, the product management community was tiny: 10–12 people, mostly contractors, no career pathway, and barely any visible leadership. Meetups were mostly venting sessions: a space to offload, not to grow. People cared deeply about their work, but the profession felt invisible.

I was still hands-on in a product team, juggling a staff-facing product platform. Anxiety over losing “hands-on” skills was real, but I also had a bigger question: what does it take for this community to exist at all?

Model

Explorers lead in uncertainty. They map the terrain, experiment, and make sense of the unknown. Key focus areas:

Safety → members must feel able to show up as themselves
Identity → defining what it means to be a product manager
Visibility → showing value to leadership and peers

Tools

Role descriptions & career pathways to clarify what a product manager does
A shared handbook capturing tips, frameworks, and learning resources
Regular meetups to build trust and a shared identity

Lessons Learned

Safety matters most; leaders absorb anxieties to protect the community.
Documentation and shared artifacts start small but grow into critical foundations.
It’s okay to begin as the single leader: shared leadership comes later.

Stage 2: Builder – Making It Last

Story

As the community grew, I realised one person couldn’t hold everything together. We went from 10–12 to 30–40 people across multiple locations. At first, I shared leadership with Senior Product Managers. Later, I introduced Lead Product Managers in each Digital Portfolio. Each Lead worked with a Head of Digital and led product strategy across that portfolio. I then matrix-managed these Leads alongside the Heads of Digital, creating a structure that balanced local ownership with strategic alignment.

Sharing leadership felt strange at first. I had been running recruitment, onboarding, and meetups myself. But letting go wasn’t just okay, it was better. New leaders improved processes and freed me to think strategically.

We also tested resilience. I took most of 2020 on shared parental leave. The community ran without me. Sure, gaps appeared, but it survived: proof that distributed leadership works when built intentionally.

Model

Builders take an explorer’s insights and make them repeatable, resilient, and scalable. Key focus areas:

Distributed Leadership → no single point of failure
Contextualisation → local teams adapt frameworks while retaining core principles
Sustainability → community survives transitions and absence of a central leader

Tools

Embedded product leads within portfolios
Geographically segmented meetups, Slack channels, and shared handbooks
Cross-government peer networks for learning and support
Indicators of community maturity to prioritise focus areas

Lessons Learned

Scale requires letting go of control, while keeping principles intact.
Hands-on work evolves into enabling others to lead effectively.
Trust is fragile; distributed leadership strengthens the community and reduces bottlenecks.

Stage 3: Architect – Connecting Ecosystems

Story

Even a strong product community risks becoming a silo. The next challenge was connecting multiple professions: product, delivery, design, research, and engineering.

Heads of Profession started meeting, sharing practices, and solving problems together. Suddenly, the professions weren’t just stronger internally, we were influencing the wider organisation. We built cross-professional communities of interest and action to make implicit knowledge explicit and reusable.

This also worked cross-sector. I attended Mind the Product and Product Leaders meetups, which helped me benchmark government practice, reduce status anxiety, and even coach commercial product leaders. These connections fed back into our own community, keeping it relevant and alive.

Model

Architects step back and design the ecosystem. They:

Connect communities → sharing knowledge across silos
Curate → highlight best work so others can build on it
Standardise → lightweight frameworks that guide without restricting
Solve once → prevent duplication and free up capacity for innovation

Tools

Communities of interest (cross-professional learning spaces)
Communities of action (spaces to improve practices like knowledge management)
Curated handbooks and shared knowledge spaces
Lightweight standards and templates for coherence

Lessons Learned

Systems thinking allows multiple communities to thrive together.
Standards and curation give “so what?” to community efforts.
Strong communities impact the organisation beyond their immediate membership.

Epilogue – What I Learned

Culture beats structure. Models help, but trust, intent, and tone matter most.
Leadership evolves. You move from Explorer → Builder → Architect. Skipping stages risks burnout or stagnation.
It’s demanding but worth it. You carry other people’s anxieties, but seeing a profession stand taller than it did before is unmatched.

Where is your community on this arc — and what’s the next stage you need to step into?

Field Notes vs Field Guides

2025-08-07T00:00:00+00:00

I’ve started thinking of my writing in two modes: Field Notes and Field Guides.

Field Notes are the messy kind: half-formed, still unfolding, shaped by the moment.

Field Guides are the ones I’d give someone else to use. They’re tested, teachable, and a bit more finished.

This blog – scottcolfer.com – is where I write field notes.

My Substack newsletter – https://productinservice.substack.com/ – is where I publish field guides.

This post is a Field Note . . . about Field Notes :)

Learning vs teaching

Field Notes are for learning. Field Guides are for teaching. Here’s what I’m noticing about them:

Field Notes	Field Guides
In progress	Tested insight
Reflective	Instructive
Personal	Practical
Curious	Confident
Relational	Useful
Honest	Helpful

Field Notes are written while I’m still in the situation. Field Guides come after I’ve made some sense of the situation. My Field Notes say ‘here’s what I’m noticing’. My Field Guides say, ‘here’s what’s worked, you might find it useful’.

Most of our work isn’t polished but most content online is. We’ve been taught to only publish when we’ve got the answer. But I don’t think that’s where the value is. Not in product, or public service, or leadership. These are fields full of ambiguity and transition. We figure things out while we’re doing them. Sometimes, while we’re writing about them. I think of this as learning out loud.

How I’m using this in practice

I keep lots of very rough field notes on Google Keep on my phone. They’re ‘in the moment’ thoughts. I turn some of these into Field Notes on this blog, using it as a chance to figure out what’s going on. I also write monthly field guides that I publish through my newsletter. I’ve got field notes stretching back to 2012, and a couple of years ago I started turning some of these into field guides. By this time, I’d been using some of these as the basis for my practice for years and they were ripe to turn into something more practical and useful. I’ve got no strict rules about this, I just do what feels right. It helps me keep going and keep sharing.

A note for anyone reading

If you’ve got an idea sitting in your notes folder because it doesn’t feel “ready” yet: maybe it’s not supposed to be a guide, maybe it’s a Field Note. And maybe it is ready?

Knowledge Metabolism

2025-07-26T00:00:00+00:00

I’ve been thinking about knowledge metabolism recently.

Transitions

I often work in times of transition:

Startup → Scale-up
Digital Transformation in theory → Messy reality of Digital Transformation
Small organisation → Medium organisation → Large enterprise
Individual practice → Collective performance
Delivery focus → Navigating complex systems
What works for one team → What works at scale
Hands-on → Middle-management → Senior leadership
Discovery → What now?
Movement → hitting a wall
Clarity → Ambiguity

Etc

Knowledge as content

And I’ve realised that, at times like this, traditional ideas of ‘knowledge management’ break down. Traditional learning can fail. Generic models can fall flat.

‘Knowledge management’ is often built on 1990s context and assumptions:

Problems are repeatable, expertise is stable, and scaling known answers is the goal
Knowledge is content, content is an asset, an asset is something to me stored, retrieved, and controlled
Knowledge management systems answer questions like “where can I find that document?”, “who has done this before?”, “can we create a template?”
Store it once, reuse it forever, build big repositories, treat knowledge like inventory.

This approach works when life is stable. But in complex systems, where context shifts constantly, static knowledge quickly becomes irrelevant and this approach starts to fall apart.

Wayfinding: knowledge as creation

In the moments of transition I shared above, the ‘path’ offered by existing, generic knowledge quickly disappears. You’re between stable conditions. The models don’t fit. Training doesn’t land.

This is when you need to learn through movement. You can’t know and then move, you have to move and then know. This isn’t the moment for training, it’s the moment for wayfinding. If you move into a new role without a neat definition, a strategy fails to land, a team disbands, a project gets messy, you’re not sure what to do next . . . you have to find your own way. There’s no neat, external knowledge that can totally unblock you. You’ve got to figure it out. You’ve got to find your own way.

Metabolism

. . . and in that wayfinding sits knowledge metabolism: You experience a disturbance and the ‘path’ offered by traditional knowledge disappears You reflect You synthesise You act You reflect again.

This is the real loop behind learning during these transitional times. Not course → quiz → certificate. But: friction → reflection → forward. At these times it’s not just absorbing information .. . . it’s digesting it, synthesising it, and transforming it into clarity, action, or movement.

Knowledge metabolism is how we make meaning, not just how we find facts. I’ve realised this idea sits at the heart of how I work, learn, and lead. It suits learning that happens during transitions, learning that has to be self-directed, reflective, contextual. The theory of this type of learning is called ‘heautagogy’ and ‘knowledge metabolism’ is the way that I help it to happen.

Just in case → just in time

Traditional learning often prepares us for things that might happen, just in case. It often comes in a big lump, in an abstracted package, before we need it. Organisations love leadership training before anyone leads, strategy decks no one uses, guidance and playbooks that don’t match the real work.

But when someone hits a wall or a moment of choice, those tools rarely help. What helps is the ability to pause, reflect, metabolise, and move again. Knowledge metabolism supports you when things actually do happen, just in time. When we don’t need more content, we need consequence. It’s how we start learning from the work we’re already doing, not adding learning on top of it. It’s how we build insight at the edge of action.

Space to think

Most organisations still treat knowledge as something you store, like inventory in a warehouse. But in complex, fast changing environments, this breaks down. The result is that learning doesn’t happen when you need it most. Over the last couple of decades I’ve seen:

Leaders promoted without support and left to figure it out silently
Teams stuck in cycles of discovery without learning
Strategic decisions made without shared understanding
Endless documentation that doesn’t build confidence or clarity.

What if even some of the money spent on ‘learning & development’ was reinvested in giving people space to think? And we trusted them to create their own knowledge? What if some of the money spent on knowledge management systems was reinvested in curating field notes that shared what was happening, on the ground – what was changing, what was being learned? What if some of the money spent on off the shelf operating models was reinvested in building field guides based on the reflections and field notes of your own staff?

This is the frame I’m starting to test across all my work. What we need isn’t more information. We need to digest what we already know, and turn it into something usable.

This is what I mean by knowledge metabolism: friction → reflection → forward.

It’s how we transform experience into insight. Not as a luxury, but as a survival skill in complexity. And it’s especially powerful and suited to moments of transition.

My Learning System 2025

2025-07-19T00:00:00+00:00

I’m a life long learner. Love. To. Learn. So it’s no surprise that I’ve spent time learning about learning.

I’m a heutagogue

I began a teacher training course in a past life. I didn’t complete it but did hear a lot ‘pedagogy’, which is the art or theory of teaching children. Later on I learned the word ‘andragogy’ which is the theory of teaching adults. And finally, I learned the word heautagogy, which is the theory of self-determined learning. This is the style of learning that ‘clicks’ with me. It comes from an old Greek word, ‘heurisko’ – one definition of which is: to find by enquiry, thought, examination, scrutiny, observation; to find out by practice and experience. My preferred style of learning means I can be accurately described as a heautagogue.

A plain language alternative to the label of ‘heautagogue’ could be that I like to notice things, reflect on them, and grow my understanding.

Learning cycles & curatated knowledge networks

I guess I have two mental models that help my conceptulise my preferred way of learning.

The first is David Kolb’s learning cycle, which was a key part of my teacher training. It provides four stages to an effective learning experience:

having an experience
reflecting on the experience
learning from the experience (abstract conceptualisation)
experimenting with what I’ve learned, incorporating it into a new experience.

The second was best described by Sari Azout as part of a blog post that I can no longer find online. It talked about community curated knowledge networks and I’ve used and adapted some of the core concepts:

knowledge: organises what I’ve learned
curation: organises knowledge around practical use
networks: groups of people that I can learn from and share with.

My learning system

This all happened naturally and imperfectly for the longest time, with me just trusting my instincts. Today though I can give it a name and articulate the system behind it. So here it is.

Knowledge: field notes

I build knowledge by noticing things and reflecting on them:

The bulk of this is my own professional thoughts and experiences. I often have them when I’m having a walk or taking a break – things that just pop into my mind
Conversations with peers are a big source of learning too, they’re a great way to reflect on something or spark a new idea. For a while I was looking at shared work spaces as a way of breaking up working from home but what I realised is it’s this deep chats that I want. So instead of that, I’ve put time and effort into regular cathups with good, interesting people.
Things shared by others in blog posts (and the occassional podcast) are useful too. I used to get a lot of this from the artist formerly known as Twitter but in 2025 it’s mainly from LinkedIn and a small amount of Substack.

I think of all this noticing, reflecting and learning as ‘field notes’, with Google Keep being the place that I store these. I have a constant swirl of field notes in Google Keep, adding, curating, and collating on my phone when inspiration strikes. This blog is a space for slightly more structure field notes, ones that I’d benefit from ‘properly’ thinking about, and/or that a small number of people might find interesting.

Curation: field guides

Sometimes the knowledge can be curated into practical guides that can directly help myself or others to do something better. I think of this as ‘field guides’. This happens when I’ve tried out my learning in real life several times, honed it and refined it, and can now confidently suggest it to others. My Substack newsletter is where I mainly do this. This newsletter started out as another space for general notes and relfection, and it got a decent amount of reads. But since I switched it into concise, practical field guides the number of readers per newsletter is 2-3 times larger and the amount of comments and likes is significantly more. I’ve also written a book on product management within complex services, which is my ultimate format of knowledge curated into practical guidance. What’s been interesting is that, having thought about and worked on the book for a year, my mental models for dicussing the job with others have come on significantly. I can quickly assess situations and suggest strategies to improve things in a way that I’ve never been able to do before. It also means that my newsletter flows much easier now, because it sits on mental models that are extremely clear ot me in my mind.

Networks

My networks bring lots of learning into me. I have my day-to-day professional experiences themselves, plus the regular 1:1s I have with peers. I run a network for product leaders in complex services, and hearing the discussions here is a great learning experience. And then there’s commercial, social networks like LinkedIn, Substack, etc where great insights are sometimes shared. All of this helps me learn . . .

. . . and they’re all places for me to share my own learning, particularly when I’ve curated knowledge into actionable field guides. There a few hundred subscribers to my newsletter, the product leaders network, and LinkedIn where I can publish and share stuff.

. . . and all of this ultimately helps in more private, practical moments when something needs to get done. It might be something I’m helping to delivey, or a chat I’m having with someone who wants to improve their approach to what they’re doing. In any case, these are the situations where this entire learning system helps me to recognise what’s going on in a situation and pull out a good first step to improve things.

That’s pretty much what my learning system looks like in 2025. It’ll change and improve over time but it feels like it’s in a pretty good place – hence I figured I’d write it up and share it. I might write-up the publishing system for my Substack at some point too.

Over to you

Do you prefer learning in a structured way, led by others? Self-led learning? A mixture of both? Have you got your own learning system?

My book: 'Product in Service: A Manifesto for Pragmatic Product Management'

2025-06-12T00:00:00+00:00

My book’s nearly finished.

Product in Service adapts product management for the service sector with a focus on non-profit services provided by National Government, Local Government, Healthcare, Education, and Charity.

Product operating models are popular in these spaces but product management rarely works ‘as is’ since it’s not designed for essential services run by large, old, complicated organisations often supporting entire nations, including the most vulnerable members of society.

How does product management work in the service sector?
What is ‘the product’ when you work on a service?
How do you overcome product purism and find a more pragmatic product management that actually works?

This book answers these questions (plus many more) and provides a manifesto for pragmatic product management based on practice (not theory or frameworks).

You can find out when it’s available by signing up for my mailing list.

I also post updates on LinkedIn and will be selling the book here.

Good Training Leads to Lightbulb Moments that Create Change

2025-03-25T00:00:00+00:00

A shared ‘lightbulb moment’ leads to change

Good training is the missing ingredient in many organisation’s efforts to change how they work. We need a ‘lightbulb moment’ if we’re truly going to change, and it’s difficult to have a lightbulb moment in the midst of hands-on delivery, with all the stress and context-switching this entails. We need space to think for a lightbulb moment to be possible. And we need our colleagues to have a similar lightbulb moment around the same time if there’s going to be organisational change.

Good training – that provides a shared experience for many people, in a safe space, away from delivery – can create the conditions for this shared ‘lightbulb moment’. Giving folks this space to think (which is so rare!) can help change to happen much quicker and more effectively than simply reaching into individual teams and tweaking their delivery. Here’s what I’ve seen.

A ‘lightbulb’ moment allows you to see clearly

What do I mean by a ‘lightbulb moment’? It’s a moment when something switches on in our mind. And a light shines on something in front of us we’ve not been able to make out, but suddenly becomes clear to us.

We can have these lightbulb moments individually in the midst of delivery but they are fleeting and quickly dim once again. Or we continue to see them but fail to share that vision with our colleagues.

I’m increasingly seeing the power of good training to create the conditions for a shared lightbulb moment across a group of people, setting them up to embark on real change.

Realisation

Over the years I’ve taken on delivery challenges, excited at the opportunity to affect change and improve how we do things. But the reality is, it’s hard to affect change in the midst of delivery. We’re not geared-up to change. Digital delivery is often, by its very nature, taking place in rapidly changing conditions. Our organisation’s often changing around us, we’re learning and adapting to our users, and we have a team of people to support and manage. There’s stress and context-switching. These are not the conditions for change.

I recently worked with an organisation to help them in their digital transformation, moving towards a product operating model. And their feedback was that two moments were the most transformative. The first was a whole-date, in person training session for the whole division. The second was a half-day, in person training session for the senior leaders. Feedback described these training sessions as creating ‘realisation’, for the first time: of where they were starting from, where they wanted to go, and how they needed to start.

This was their version of collective lightbulb moments. Training provided a space to think, away from delivery, alongside colleagues. A switch went on and they saw something in front of themselves clearly for the first time, at the same time.

Good training

I’ve used the term ‘good training’, because some training is more likely to create this shared lightbulb moment than others. I’ve worked in organisations that’ve sent folks on things like a shared Scrum bootcamp that doesn’t have the same results. Even if folks find the training interesting, their organisation is not ready to use ‘pure’ Scrum yet and so the gap between the training and reality is frustrating and the knowledge quickly dissipates, leading to disappointment.

The training in the example above that led to moments of ‘realisation’ was designed for the organisation itself, it wasn’t an out of the box approach. Each session had a run-in time of a month, allowing us to understand the people and their needs, and creating something for them. The approach to the sessions themselves was facilitative, not lecturing. There was certainly knowledge shared but more time was spent on asking powerful questions and giving people space to think and comes to conclusions they owned. This is what I’m thinking of when describing ‘good training’ in this context. Good training may be missing

Looking back at my experiences and the experiences of my peers, I can see positives when this training is present and gaps when it’s missing. When teams are being told they need to change but don’t have space to understand and figure out why this is the case, how it will help them, and what they need to do – the change just becomes another noisy element of delivery. When I’ve seen people and teams invest in facilitative training that provides a safe space to think, it has led to these shared lightbulb moments. It also improves the change – all of those people and brains and experiences in the room improve the reasons for change and how to make the change.

Make space for lightbulb moments with good training

I see excellent people (in-house folks and consultants) leading change from the front through delivery but struggling to land this change in a lasting or pervasive way. I’d love to see this people give time and space to lead on shared experiences, outside of delivery, setting the conditions for lightbulb moments, at scale.

We still need to make change within delivery too, but these shared lightbulb moments reduce the friction that often comes with change. Because people have been given a safe space to think, alongside their team, sharing an experience of understanding where they are, where they want to go, and where they’re going to start.

I’ve seen good training lead to these lightbulb moments. I have to admit, I’ve not always recognised this. I’ve been scattershot in my approach to training in the past when responsible for communities of practice. But I’ve had my own moment of realisation now and am factoring good training into my approach to strategy and transformation.

What’s your take?

Do you manage to make time to think within delivery? Have you experienced a great, shared experience that led to a ‘lightbulb moment’?

Scott Colfer helps organisations with product leadership, product management, and product operating models. This often includes help with strategy, and help with transformation. Connect on LinkedIn.

Professional Pivot: Director of Strategy and Transformation

2025-01-29T00:00:00+00:00

In January 2025 I changed from ‘Director of Product’ to ‘Director of Strategy and Transformation’– not to change what I do – but to give a better name to what I already do.

Beyond product

2018 was the last time I focused on just the product management profession, truth be told. That year I started leading on the overall standard and value of work done by whole product teams. Fast forward to 2021 and I led a team of Heads of Profession across business analysis, content, delivery management, design, product management, and user research – leading in improving how our professions came together in teams to do valuable stuff for users. Fast forward again to 2022 and I joined a leadership team restructuring a large organisation – leading on migration of business critical systems to form a new Digital team – whilst leading on creating product ways of working.

Introducing

If I think about it, strategy and transformation have been consistent themes throughout my career. Lots of my career has been spent introducing new tech to organisations – laptops, the world wide web, software as a service, mobile devices, apps, games based learning, . . . and much more. Ways of working too – customer insights, agility, design thinking, customer validation, lean, DevOps . . . the ways of working keep on coming too.

Coordination

In the last couple of years I’ve been helping organisations implement a ‘product operating model’ or ‘product ways of working’ and what I see is a challenge of coordination. Lots of new technologies and ways of working have been introduced over the last couple of decades and we’re left with the end result of multiple transformations that never quite finished and don’t link together. At their best, modern digital transformation coordinate organisations, helping the individual parts to work together, radically focused on the same goals. Product remains my anchor point and a specialism for me but the work of successful transformation goes way beyond product management. I’m increasingly working with and across product and delivery, PMO, service operations, solution architecture, research, education, publishing . . . helping build shared strategy, and coordinating joint efforts to achieve their strategy.

It’s what I love and what I’m good at. Still product at heart but pragmatic and inclusive in practice.

Introducing New Wave Product

2024-08-26T00:00:00+00:00

Start with why

I’m writing a booklet called ‘New Wave Product’ that’s a sort of manifesto for pragmatic product management. Most popular guidance feels ‘purist’ and narrowly focused on metrics-driven tools, models and frameworks.

Entry and mid-level product managers I’ve managed and met will hoover-up this purist guidance, find it doesn’t work in the messy reality of their organisation and feel like they’re not doing proper product management.

Lots of organisations wanting to be ‘product-led’ will spend time on OKRs and roadmaps and introducing product managers but realise this doesn’t address their underlying problems.

My truth is that a roadmap never really changed anything. The popular tools, models and frameworks can be of help but it’s coaching, managing change and negotiation that have led to the transformation in my work.

I think product’s up in its head and needs to get out into the world and be a little more pragmatic. ‘New Wave Product’ is an argument for broadening product culture so we can think about people as much as metrics. It’s a call for pragmatic product.

How

‘New Wave Product’ will likely have five sections explaining where we’ve got a little lost and how we reintroduce pragmatism. There will be:

an introduction improving and expanding on this blog post
a section on the mis-adventures of an organisation becoming ‘product-led’ as a vehicle for digital transformation
a section on the experiences and signals over the years I missed, all of which were telling me that something was missing in how we often define product
a little inconoclasm, returning to our sacred texts to see their strengths and weaknesses
and finally the key principles for new wave product as a call to action and a manifesto for pragmatic product.

I’ve been writing blog posts since the 2000s and writing product-guidance for over a decade, including the popular Product Management Handbook from 2018. I took the Faber Academy’s ‘creative non-fiction’ course at the beginning of 2024 which helped me find my own voice and improve my storytelling.

What

I’m doing this as an A5 booklet, probably around 16 pages in length. I’d like to draft this in just a couple of months and I’d like people to read it in a few minutes. I’d like to do the hard work to make it simple. I’ll print 25-50 copies of the draft and share with folks for feedback, then improve, then do the same thing with a slightly larger print run. I’m going to keep things as simple as possible and strip out anything that distracts from getting it out into the world asap.

Updates

You can sign-up for updates here and connect on LinkedIn.

Product Leaders for Good WhatsApp Community

2024-03-23T00:00:00+00:00

Get in touch if you’d like to join a community for product leaders in the public sector. The best way to get in touch is to connect with me on LinkedIn. Or you can comment below.

Why

Product leaders need safe spaces to share and learn from one another. But we don’t have many of these spaces. Public sector product leaders are especially poorly served, with a lot of stuff aimed at commercial sector.

Personally, I’ve hit the public sector trifecta of Central Govt, Local Govt and Charity product leadership roles and realised we all have the same problems and same opportunities. I’ve been working in Higher Education rcently and the same is true. My personal aim is for us to have a safe space. And somewhere to support the next generation of product leaders.

I took a punt and shared a LinkedIn post inviting folks to join this new thing, figuring we might get 10-20 interested.

Who

We’ve quickly gotten to 58 people across Central Govt, Local Govt, NHS, and Charity. Ace!

Anyone wanting to join with a title of Lead Product Manager, Principle Product Manager, Head of Product, Assistant Director of Product, Director of Product, or Chief Product Offier is immediately approved. For others I review their role - we don’t want to be purist around roles - we do want this to be a safe space for people with similar challenges and opportunities.

I’m facilitating the community to get it off the ground. I’m doing this as me, Scott. Herd, where I work is sponsoring this by allowing me to do it ‘on the clock’. And have agreed there is nothing expected in return, it’s simply a way of accomplishing our social mission to support the professions of product management and business analysis. Some folks from the community are going to join me in facilitating in the next couple of weeks so leadership and ownership will inreasingly be shared.

How

We use WhatsApp Comunity. WhatsApp’s worked best of the social media platforms for professional stuff in the past so took a gamble it’d be the same here. So far, so good. WhatsApp Community lets us have a single main community. And loads of topic-based chats people can choose to be in or not.

What

We share and support each other in a safe space. Topics include platforms and components, programme –> product, meetups, recruitment. And stickers.

Our first meetup is a lunchtime videocall. Microsoft Teams is the most accessible software to use.

And we’re going to arrange our first real life meetup.

Get in touch if you’d like to join a community for product leaders in the public sector. The best way to get in touch is to connect with me on LinkedIn. Or you can comment below.

My Social Media Triad for 2024: Substack Journal, GitHub Pages Blog, and LinkedIn Network

2023-10-10T00:00:00+00:00

My social media triad in 2024 will be: Substack newsletter - GitHub Pages blog - and LinkedIn network. Here’s where to find me and why I’ve designed my online world like this.

Substack Journal

A newsletter feels the most sociable way of sharing things in 2024. I want to publish and share stuff but don’t want to spam the folks. People get to choose if they see my newsletter by choosing to subscribe or not, which feels like the right balance between putting stuff out there without getting in people’s face.

I’m using my newsletter like a journal, much liks the early days of blogging. Each newsletter pulls together three topics: the only thing they have in common is that I enjoy them and want to share them. Topics include are likely to include: product management, coffee, digital transformation, e-bikes, knitting, short stories, coaching, mental health, tea, obscure Youtube scroll-holes. I enjoy learning and simplifying concepts and ideas. It helps my understanding. A happy byproduct is that I’m good at sharing ideas with others, something else I enjoy.

Substack kept coming up as the top recommendation for a small newsletter so I gave it a try and like it. Substack Review: Features Summary for 2023 by Nick Wolnywas useful to see an overview of newsletter platforms along with more info on substack. Should I Start a Substack by Lexi Merritt helped me to commit and give it a try.

I share three things at a time. And keep each thing simple and brief. I publish a newsletter when I’ve got something interesting to share and stay quiet when I don’t. Read the archives and signup here.

Github Pages Blog

This blog, scottcolfer.com, is my online home and has been for a long time. It’s where I reflect and share new ideas. Writing and publishing helps me to reflect and learn, then test with others, and help others in the same situation. So many people have told me that it’s helped or entertained them (sometimes both).

I used a self-hosted WordPress blog 2009-2015 but became frustrated that backing-up posts wasn’t easy. In 2016 I moved over to GitHub Pages. The way it’s structured makes backing-up my posts much easier. And working in GitHub with basic HTML and CSS helps me to keep my awareness of code (since stopping being a ‘hands-on’ product manager and becoming a product leader).

GitHub hosts a free, static site for each user through GitHub Pages. GitHub Pages can be married with Jekyll to create a blog hosted on GitHub. I followed an excellent tutorial by Jonathan McGlone has published an excellent tutorial. The tutorial assumes very little knowledge and covers Git (version control system), GitHub (hosting service for development using Git), GitHub Pages (free web pages from GitHub) and Jekyll (a ‘static’ site generator, based on templates). You’ll then start writing blog posts using Markdown. You can see the publishing and development history for my blog in my public GitHub account.

scottcolfer.com is my long-term home online. It’s been valuable over the years to help me reflect and learn, to help others, and to build my professional reputation. And it needs to be part of a network if anyone’s ever to see it.

LinkedIn Network

I’m active on LinkedIn and finding it useful. This time last year I wasn’t. What’s changed?

Twitter was my main social network for work from 2008 but last year there was a lot of kerfuffle. Since then lots of people in my network drastically cut back on their tweeting. Some people left completely. My Twitter is a much quieter place now. Lots of people moved to Mastodon, then Threads, then Blue Sky. I’ve tried them but they haven’t ‘stuck’ for me. I’m looking for a casual platform that I can dip in and out of without a lot of effort . . .

. . . and LinkedIn was there, ready and waiting. For me it has a pre-built network of 800+ professional contacts stretching back to 2009. LinkedIn’s been there, in the background, for lots of people for a long time. It’s more casual than other platforms, you can dip in and out of it, and that’s . . . nice. I take a look every few days. I’ve got some interesting chats going on in the background via messages. It’s a good way to see what folks are up to. People post interesting and useful stuff andf the amount of chat and feedback actually trumps Twitter. You can find me here if we’re not already connected.

That’s my social media triad for 2024. I reckon it’s a year where lots of people will shuffle their own online presence and come to a new figuration. What will you be using?

The Science of Strategy

2023-06-25T00:00:00+00:00

The Kernel of Good Strategy

I told people on LinkedIn I’d read ‘Good Strategy Bad Strategy: The Difference and Why it Matters’ by Richard Rumelt. It got a surprisingly large reaction. I particularly enjoyed the challenge laid-down in one comment: ‘what’s the short version?’. Here it is:

Problem: A lot of strategy is bad.
Diagnosis: bad strategy fails to face problems. Bad strategy focuses on ambition, leadership, vision, goals or competition without engaging with reality as it is now and how to play in it
Theory: Good strategy focuses on the biggest problem facing you right now. Good strategy seeks to turn a weakness into a strength.
Coherent actions: Build the ‘kernel’ of a good strategy by
- defining your main problem
- diagnosing the reason(s) for the problem
- defining a theory of how to overcome the problem and turn it to an opportunity
- building a choerent and feasible set of actions to bring your theory to life.
That’s my digested version of Good Strategy Bad Strategy.

No strategy survives first contact with reality

A running topic in 1:1s with my Lead Product Managers over the years has was strategy that lacked strategy. A big corporate strategy would appear - let’s call it a STRATEGY! - and we’d pick over why it wasn’t a strategy. Typically it would be a wishlist of actions. Or a set of aspirational goals lacking a benchmark or a target. It’s more marketing material than useful strategy. A lot of people would then spend a lot of time trying to explain their work through this ‘strategy’. And within 12 months the STRATEGY! would disappear, everyone would breath a sigh of relief and carry on with their work. Until the next dastardly STRATEGY! appeared to ruin the day. Me and the Lead PMs developed a shorthand for what we wanted from a strategy, and it’s changed over the years:

first of all, we described it as a goal with a plan for how to achieve it
then, I tweaked this to a goal with a theory for how to achieve it (dropping the ‘plan’ bit)

But this was still unsatisfactory as a guideline for a good strategy. The problem I’ve seen with lots of strategies is the leave a gap with reality. The STRATEGY! - really a set of aspirational goals or a whislist of actions - help people to focus on the same words but doesn’t help people know where to start. There’s loads of work and loads of problems here, today . . . and the STRATEGY! doesn’t connect to them. It floats free of reality. And leaves us to scratch our heads - we know what the big vision is but what’s step one? How do we bring this to iife?

Let’s misquote Helmmuth Von Moltke

There’s a saying, ‘no plan survives first contact with reality’. It’s meant to convey that all the planning in the world often can’t anticipate the messy, complex reality of life. It’s also a misqoute, a Prussian military commander called Helmuth Von Moltke is actually attributed as saying ‘no plan of operations reaches with any certainty beyond the first encounter with the enemey’s main force’. But that’s not as snappy, so why let the truth get in the way of a good story? And with that sentiment, we can tweak this further to, ‘no strategy survives first contact with reality.’

Reading ‘Good Strategy Bad Strategy’, I’ve got a new take on what a good strategy is:

‘A strategy is a hypothesis and its implementation is an experiment. Rests on hard-won knolwedge created through scientific empiricism. It does not come from strategic management model, tool, matrix, triangle. It does come from a talented leader identifying the one or two critical issues in a situation.’

This makes sense to me. A good strategy doesn’t seek certainty beyond the biggest problem facing you. That is the focus of the strategy. Once your strategic experiment is over and you’ve either solved the problem or not, you move on to the next iteration of your strategy. That’s what it boils down to: figure out how to solve your biggest problem. In doing so, you work in reality. You don’t leave a gap where people have to figure out what to do to implement it. You fill in the gap so it’s immediately useful.

‘Good Strategy Bad Strategy’ has lots more valuable insights. Here’s the longer version of what stood outfor me.

Bad Strategy

Bad strategy flourishes because it floats free of analysis, logic or choice.

Bad strategy is earmakrked by:

fluff: gibberish. buzz words. masquerades as expertise.
failure to face the challenge. if the challenge is not defined we can’t assess the quality of the strategy
goals mistaken for a strategy: strip out ambition, leadership, vision, planning, competition. These are all signs of bad strategy.
bad strategic objectives that fail to address issues or are impractical
active avoidance of obstacles
spreading recources rather than focusing them: Having confilicting goals, dedicating recources to unconnected tagets and accomodating incompatible interests
a laundry list of desirable incomes
an absence of saying ‘no’
following a template such as
- Vision: popular is ‘to be the best’ or ‘be the leading’ or ‘be the best known’
- Mission: fill a high-sounding, politically correct statement of your purpose
- Values: Fill in a statement describing your values. Make sure they are non-controversial.
- Strategy: Fill in some aspirations/goals but call them strategies.

Good strategy

A good strategy honestly acknowledges the challenges we face and provides an approach to overcome them.

Good strategy is earmkarked by:

discovering the critical factors in a situation and finding a way to coordinate & focus action to deal with those factors.
harnesses power and applies it where it will have the greatest effect. It draws power from focusing minds, energy and action. This is about application of power to the right target. It’s about focus and therefore choice
uses the power of leverage, finding a pivot point to magnify the effects of focussed energy and resources.
a scientific approach. It is a hypothesis. And provides a safe space to test those hypotheses.
good knowledge of the specifics. There’s no substitute for on the ground experience.
defines the kernel of the strategy
- the problem
- diagnosis: Use chain link logic and look for weakest link. There’s no point strenghtening all of the links if a weak link remains. Note that when each link in the chain is managed sepately the system can get stuck in low effectiveness. If you are the manager of one link in the chain there is no point investing resources in your link in the chain if others do not
- guiding policy: outlines an overall approach. It channels action in certain directions without specifying exactly what shall be done. It’s not a vision or a desired state, it’s a method of grappling with a situation and ruling out an array of possible options. Design is important. It’s less about making a single decision and more about designing a set of complimentary policies. More construction than choice. Various elements must be aligned for strategy to work. There are gains to getting combinations right and costs to getting them wrong. The opposite of chaos isn’t order it’s harmony
- coehernt actions: resource deployments, policies and maneuvers, all coordinated, feasible and actionable.

Boilerplate kernel

I just gave myself a few minues to create a boilerplate kernel of a good strategy for public sector digital work - based on quotes and ideas from Good Strategy Bad Strategy (it feels like a neat way of pulling my notes together).

‘In large organisations the challenge is often diagnosed as internal. The organisation’s competitve problems may be much lighter than the obstacles imposed by its own outdated routines, bureaurocracy, pools of entrenched interest, lack of cooperation across units, and plain old bad management. Thus the guiding policy lies in the realm of reorganisation and renewal. And the set of actions are changes in people, power and process.’

‘The cost of decentralisation can be a loss of coordination across units. We’re often trying to overcome inertia:

inertia of routine: the pulse of the standard procedures for operating the organisation. Counter this by simplifying procedures. Eliminating complicated processes, routines and attempts to hide waste and inefficiency. Strip out excess admin and halt nonessential operations
intertia by proxy: if our people we work with are slow to change then we’re slow to change by proxy. This disappears when we decide that adapting to change is more important than hanging on to everyone’.

‘Create a proximate objective - one that is close at hand to be feasible. Name a target that we can expect to hit, even overwhelm.’

‘Reduce cycle time - our products and services will be leading more often the shorter our cycle times are - and our performance gets better.’
‘Anticipate something to get ahead. Ride a wave of change.’
‘Start small and start ‘safe’.’
‘Try to destroy your own ideas.’

That’s what I took from ‘Good Strategy Bad Strategy’. Does it make sense to you? Is it of use to you? Have you read the book? Did you take something different from it?

Scott Colfer's Guide to Making Coffee at Home

2022-09-13T00:00:00+00:00

I’ve been making coffee at home for ages now and have learned a few things. I’ve been blogging about coffee for quite a while too. I figured I’d pull all this together in one place: here’s my guide to making coffee at home.

Brewing your own coffee (starting simple)

If I was just starting making fresh coffee at home today I’d probably choose a simple brewer like a French Press, a filter, or an Aeroporess. They’re all a pretty cheap way to start, and fairly easy way to learn. So how do you choose which one to go for? Back in 2018 I wrote a post to help choose a coffee brewer based on what it does for the taste of the coffee:

on one end of the scale, filter coffee produces light, delicate coffee (because it filters out a lot of the solids and the oils)
at the other end of the scale, French Press produces strong flavours (because the ground coffee is immersed in the water)
in between, an Aeropress allows you to get a bit of both.

I published posts on my method for brewing filter coffee, brewing with a French Press, and brewing with an Aeropress . . . but I oringinally wrote them a long time ago on a (now defunct) food blog I used to run, then ported them over here a few years later. They’re not the method I’d use now. And more importantly, coffee guidance has moved on a lot since I started all this in the early 2010s. Nowadays I’d recommedn James Hoffman as a good starting point, see his videos on French Press, filter coffee and Aeropress.

If I had to choose my favourite of the three to start with I’d suggest the Aeropress. It’s the most versatile my far. If you tweak your method, you can use it to create something that’s pretty close to filter coffee or French Press coffee. And loads of variation in between.

Gateway to espresso

It’s difficult to make good espresso at home. But I started making coffee at home in the 2010s when it was pretty difficult to get much guidance and I accidentally went in at the deep end with an espresso machine . . . and then had a bunch of baristas tell me they’d never make espresso at home. So I wrote a post called don’t make espresso at home (probably).

If you’re really interested in making espresso at home then a moka pot (also known as a stove top pot) can be a good way to get familiar with the basic principles in a cheap way. You’re not creating espresso when you make it, it’s still brewed coffee. But it’s still nice, and allows you to build familiarity with some of the basic principles of making espresso. Obviously, James Hoffman has a decent video on how to make coffee with a moka pot.

There’s a new (2-3 years old) product called a 9Barista that makes genuine espresso. But it’s small, so doesn’t take much space. Works on the stove, so doesn’t take-up a plug socket or counter space. And is locked-down and simplified. So it means you can get to grips with the core aspects of making espresso in the simplest way possible (without getting a fully automatic espresso machine). I got one during the pandemic and wrote on post on how to make espresso using a 9Barista.

Making espresso at home

Ok, here it is. My favourite way to make coffee. I always come back to espresso. For the longest time my espresso machine was a Gaggia Classic. In 2019 I wrote a post on why espresso is my favourite coffee to make at home, and how I use my Gaggia Classic. My old machine finally stopped working earlier this year and I wrote a post on my top 3 tips for looking after a Gaggia Classic. I just worked backwards from the reasons that mine stopped working (long story short: a LOT of limescale, thanks London water - so clean and descale regularly).

My new machine is a Miss Silvia from Rancilio Silvia. It’s ace. I wrote a post on how I chose it, set it up, and use it to make espresso.

And finally

Coffee shops have been a lovely part of my life for a long time and there are several I have fond memories of. I’ve written about a couple of them, like Flat White in Soho and the original Prufrock when it was in Shoreditch. There have been loads more over the year, all over the country - I might write about some more one day, a short book about coffee places would be fun to put together. My current regular is Dark Arts in Hackney.

Choosing, Buying and Setting up a Rancilio Silvia Miss Silvia Espresso Machine

2022-07-27T00:00:00+00:00

I had to retire my Gaggia Classic after 10 years and decided to get a new espresso machine to replace it. Here’s a post about why I decided to buy a Rancilio Silivia Miss Silva, how I bought it, how I got used to it, and what I’m going to try next.

Choosing a Rancilio Silvia

My first question to myself was: do I want to give-up on making my own espresso? I decided ‘no’, I enjoy my morning ritual of making espresso for myself.

My next question was: do I want to take this opportunity to upgrade my machine? I decided ‘not really’.

Using a machine like a Gaggia Classic is vaguely like driving an old, mechanical car that has no speedometer or warning lights. A Gaggia Classic is a mechanical boiler in a casing. It has a light to let you know when the water’s hot enough and that’s it. At it’s price point (around £500 or less), that’s all you get with most models. If you pull an espresso shot and it takes good or bad it’s difficult to understand why. Was the pressure right? Was the temperature right? It’s trial and error. The next step-up includes the equivalent of a car dashboard that let;s you track these variables. But the next step-up is a lot more expensive. You jump from around £500 or less for machines like the Gaggia Classic, to £1000-£1500 for machines with a lot more diagnostics and a second boiler. There’s little in between. And a price-jump of that size deserves a pause for thought.

I decided that this price-jump was not good value for me:

I’ve not exhausted what I can do with what I’ve got. I can get better by giving more attention to how I make espresso with my existing setup. There are options at the £500-ish price-point that can be modified to add additional functionality, if that’s something I’d like to do that in the future
I’m only making espresso for myself and only once a day. There’s close to no purpose in having a second, dedicated boiler for steaming milk when I’m using the machine so lightly
I’d end-up being limited by the quality of my grinder and unable to make use of the quality of an upgraded espresso machine. The rule of thumb is your grinder needs to be of the same quality as your espresso machine if you want to get good results. My Gaggia Classic cost around £180 back in the day, and that’s how much my upgraded grinder cost when I got it a few years later. They’re evenly matched. If I spent £1000-£1500 on an espresso machine I’d need to invest £500+ on a grinder. And I couldn’t afford that. £1000-£1500 would max-out what I could afford. And without the grinder to back it up, I wouldn’t get the benefit from it. It’s likely that a £500 espresso machine and a £500 grider would get better results than a £1500 espresso machined and a £200 grinder. So, on balance, it’s better for me to get a £500-ish machine - that I can still get better at using - and consider upgrading my £200 grinder to something more around £500 when I can afford it in the future.

However, I decided not to get a more modern Gaggia Classic. I’ve gone for a Rancilio Silvia Miss Siliva instead. It’s a similar machine in many respects, kind of a step sideways in many respects. But it’s a better quality of build in terms of materials and construction so it’s kind of a tiny step-up in that I should get more consistent results and it could last longer than the Gaggia. It’s similar enough that I should be able to use it straight out of the box. And enough of an improvement that it should be a pleasure to use. Gaggia Classic and Rancilio Silvia are the two most popular semi-manual espresso machines at this price point. This is in part because they can both be modified and improved with relative ease. As a result, both have large support communities to help get the most from them.

Buying a Rancilio Silvia in the UK

It’s not as easy to buy a Rancilio Silvia as I’d expected. It’s not hard but required a bit of research. I could only find two authorised sellers of Rancilio Silvia in the UK, Bella Barista and Coffee Italia. I’ve used Bella Barista before so tried them first but they had no stock during the couple of weeks I checked their site. I’d not heard of Coffee Italia before but a quick search showed a lot of satisfied customers, they had Rancilo Silvia in stock and on offer for £492. So I went with them. Delivery was £20 but the machine is relatively heavy and ships from Italy so that seemed fair enough. It was sent by Fedex, I got regular updates and it reached me in less than a week. It arrived well-packaged in perfect working-order.

Getting used to the Rancilio Silvia

The Rancilio Silvia comes with simple instructions for how to prepare the machine for first use. Unusually, it’s packaged with a decent tamper too.

The machine ships with a ‘double’ basket . . . but the maximum it’ll comfortably take is 16g of ground coffee. I typically go with the increasingly common 18g of ground coffee for my double espresso. So I ordered myself a larger basket but carried on using the machine using 16g of coffee until it arrived. It’s worth noting, the Rancilio Silvia group head is different to the Gaggia Classic. It needs different portafilters and different baskets, so I couldn’t use the larger basket I’ve got for my Gaggia Classic.

I’ve had my larger basket for a few days now. The Rancilio Silvia is so close in features to the Gaggia Classic that I’ve not had much of a learning curve to get up to speed and I’m already making consistently decent espresso. My workflow is:

Water tank full of filtered water
Turn on the machine with the portafilter attached and leave to warm-up (cup on top to warm too)
When water is ready, flush through the steam wand and the grouphead to ensure machine is fully warm
Grind 18g of coffee beans. I’ve got a Sage Grinder Smart Pro and am currently using espresso blend from Workshop Coffee. I grind finely at setting 6 for around 14.4-14.6 seconds. Then tamp the grinds firmly
Take my scales, place the cup on top and zero them. Remove the cup and place the scales on the drip tray
When the machine’s hot, attach the portafilter, place the cup underneath on the scales and start the water
I turn-off the water at about 31-32g of espresso and it runs for a little while longer to give around the 36g of espresso I’m looking for.

I’m getting good results so far.

There’s a few things I might do to try and improve things in the future:

There’s a weird design choice on the Rancilio Silivia. The screw attaching the water screen to the group head is not flush to the screen. This means you get an indentation in the coffee puck every time you make an espresso. My assumption is that this indentation creates a weak point for water to funnel through, probably messing with the espresso’s flavour a little. There are kits available to sort this, I’ll likely get one
I’ll probably get a naked portafliter. It makes the workflow a little simpler. The spouts on normal portafilters leave little space underneath for espresso cups and scales, naked portafilters leave more space and make things easier. They make me enjoy the process of making the espresso a little more, it’s satisfying to see the espresso coming out of the machine
I recently published a post on things I’ve learned from owning a Gaggia Classic for 10 years. Off the back of that I’ll be cleanging my machine every month and descaling every 2-3 months
My espresso machine is now better than my grinder so I might consider upgrading my ginder at some point. The Niche Zero seems to be what all the cool kids are getting at an equally cool £500
There’s a whole thing about pressure of espresso machines at the moment. 9 bars of pressure is ideal but many machines, like the Rancilio Silvia, ship at a higher pressure. I’ve not encountered any issues as a result of this so far. But it’s relatively simple to change and something I might try.

That’s it for now. Happy coffee making!

3 Tips for your Gaggia Classic (after I owned one for 10 years)

2022-07-22T00:00:00+00:00

I just retired my Gaggia Classic after ten years of trusty use. I learned a bunch over that decade and figured I’d jot it down and share it in case it helps you.

Here are three tips for extending the life of your Gaggia Classic or Gaggia Classic Pro to ten years and beyond. And for getting good quality espresso throughout your machine’s lifetime. These tips are learned by having a machine for a long time and not easily found on the web. I reckon I’d have gotten 15-20 years from my machine if I’d known these tips when I started out. The main thing I’ve learned is that the Gaggia Classic isn’t really a consumer device, like a food blender or a kettle. It’s better to think of it like a professional device shrunk and simplified for the home. It needs to be cleaned. It needs to be descaled. Occasionally it’ll need to be serviced. It needs looking after.

Context is important, here’s mine. The Gaggia Classic is a semi-manual espresso machine for making coffee at home. I had an old-model Gaggia Classic but most of these tips are equally useful for more recent models and the Gaggia Classic Pro. I live in London (England, United Kingdom) which is significant in a couple of ways: my home city has ‘hard’ water; and I will reference products from my territory but you’ll probably be able to find your own versions closer to home.

Tip 1: Descale your machine

I’ll start with the tip I learned latest and I wish I’d heard earliest. Descale your machine. Remember I said I live in London and it’s a ‘hard’ water area? Well this is the reason my machine’s retired. I didn’t descale my machine the whole time I owned it. Limescale built-up in the Gaggia’s boiler until it was so bad it started breaking-off and clogging the machine. It was bad. And beyond the point of realistic repair.

So what would I do differently now I know what I know? Descale my machine. Every 2-3 months (because I live in a ‘hard’ water area). This video from Whole Latte Love show’s what happens when you don’t descale your machine. They also published a video on how to descale your machine. Here’s another video from Tom’s Coffee Corner that goes into a little more detail.

A build-up of limescale can be fatal for your machine (like it was for mine) but there are situations where your machine can have a full service and live to make coffee another day. There are professionals who’ll do this for you. Or, if you’re feeling brave and have a high-risk appetite, you could try it yourself. See this video on how to do a full service and descale I have to be honest. I’d think twicee about doing this myself as it’s involved and can go wrong. But if you’re machine is so bad the alternative is you’re going to ditch it, you’ve got nothing to lose.

In a city like London the advice is to descale every 2-3 months. Other areas with better water might get away with a couple of times a year. This further depends on useage. I make one double espresso a day, if you make more than you need to adjust accordingly.

Tip 2: Filter your water

Hot on the heels of talking about descaling, it makes sense to talk about water. Water is the main ingredient in most coffees so it’s worth making it decent. I discounted using bottled water because it’s wasteful. I tried Brita water filters for a while but felt they still involved a lot of wasted plastic. I got bored one day and cut a filter open to see what’s inside - it’s a mix of charcoal and beads. After doing some research I found that activated charcoal performs the same function as a Brita filter but with less waste, so I tried those for a while. They do work but the downside is they take a relatively long time to work. With a filter, you pour the water through and you have filtered water normally within a couple of minutes. With activated charcoal, you immerse it in the water and have to wait 5-6 hours + before it’s done it’s thing. Nowadays I’ve found a happy medium called Phox. Phox is a British company that manufactures and sells water filters. The filter itself can be reused - you just buy a sachet of charcoal to refill it every month or two. Quick results and a little less wastage.

It’s worth being up-front: I got a build-up of limescale even with this filtering. It’s hard to filter-out everything in water, particularly in a hard water area like London. Over time it’ll build up. Filtering water will make your espresso taste better and might delay the need to descale but it won’t remove it.

Tip 3: Clean your machine

Water stopped flowing through my Gaggia Classic after 5-6 years. I figured this was the end and started researching new machines. Something told me I should do a bit of research into common reasons for water to stop flowing out of the group head and I quickly learned something obvious: machine’s get dirty over time if not cleaned regularly. Eventually old coffee builds up and blocks water. I simply hadn’t cleaned the machine for a long time.

This was the first time I’d done some maintainance on the machine and it felt a little daunting at first but, as ever, Youtube came to the rescue with loads of guidance. This video from Christoph Biallas is what I’ve used most often to get step by step instructions. I got the cleaning kit (a backflush basket and cleaning powder) from Doppio coffee because they have a store near me. I’ve been lazy and only cleaned the machine when the water stops (probably about every three months in the last few years of having it) but think I’ll do it more often with my next machine, aiming for at least once per month. It’s a pain but makes a huge difference to how well the machine runs which in turn improves the quality of your espresso.

———————

To resummarise, I slowly learned that a Gaggia Classic isn’t really a consumer device like a food blender or a kettle. It’s better to think of it like a professional device shrunk and simplified for the home. It needs cleaning, descaling and servicing. If it’s looked after, I reckon a Gaggia Classic or Gaggia Classic Pro could last 10-20 years making good quality espresso.

There’s lots of other tips for making good espresso and they already exist. I’ll point you at them rather than recreate them. There’s a vast amount more accessible information on making espresso at home now versus when I started a decade ago. Back then it was mainly word of mouth or coffee forums and both of those were hit and miss, as likely to confuse you as help you. There’s a wealth of accessible guidance in 2022 that means you can learn and improve quicker than I did.

I shared how I make espresso with a Gaggia Classic after eight years of ownership and published a post on reasons not to make espresso at home a couple of years earlier.

James Hoffman’s Youtube channel is probably the most popular coffee series you’ll encounter. There’s loads on all aspects of coffee to help improve how you make it and how you appreciate it. There’s a load on espresso including the birth of espresso, the best espresso machine under £500, a beginner’s guide to grinders, how I make espresso, understanding espresso dose, understanding espresso grind size, understanding espresso ratio, espresso drinks explained, and everything you need to know to steam milk.

Other Youtube channels that I’ve found useful are Seattle Coffee Gear and Lifestyle Lab for reviews of kit, and Whole Latte Love for guidance on how to use and look after your kit to make good coffee.

My Gaggia Classic was a great machine that lasted for ages. I can heartily recommmed one and with these tips yours might last even longer.

Scrambled Eggs

2022-07-10T00:00:00+00:00

No one: . . .

Me: Let’s talk about scrambled eggs.

Product managers love food

Most of the posts on this blog are about product management. There’s a lot of product managers who’ve become friends. And most of our conversations inevitably move on to food at some point. Is it that most product managers love food? Or that the ones that love food are the ones I become friends with? I think a bit of both. But I’ve got a theory. Product managers aren’t the ‘doers’ in their teams. If we’re doing our jobs well, we don’t tell teams how to do their jobs. We define what we need to achieve and why we need to achieve it. So much of our role is about listening, thinking and speaking. Hopefully in that order. And that can be frustrating. Sometimes we want to get ‘hands on’ and do something ourselves. But that’s not really the job. So my theory is: we develop deep, creative hobbies out in the real world to make up for it. So I think most product managers I’ve gotten to know have a deep love for food. It’s certainly true that I do.

The boy can cook

Once upon a team in a former life I had a moderately successful food blog called ‘The Boy Can Cook’. It doesn’t exist any more. I’d guess the only evidence it ever existed now would be to lookup historical registrars for the domain theboycancook.com, such is the ephemeral nature of publishing on the world wide web. If you looked at the history of this domain I think you’d see someone owned it from 2010-ish to 2014-ish. That person would be me. I might write about it another time.

That time was representative of a phase, probably early 2000s until mid-2010s, where me, my friends, and then my partner were ‘foodies’ in a London, social media-centric kind of way. We’d go to the pop-ups, the street food stalls, the markets, the restaurants that had an online buzz.Joined some pretty cool food events. We’d try out pretty challenging, frequently impressive recipes. The 2000s was a great time for this group of 20-somethings to expand our food horizons after growing up with Push Pops and alcopops in the 80s and 90s.

And then it dropped-off for a bunch of reasons. Personally, I still enjoy ‘buzzy’ food every now and again. But here, today, in 2022, I mostly enjoy everyday basics done well. Like scrambled eggs. It’s a decade-ish since I last published a post about food, a decade in which I switched to posts about product management. But variety is the spice of life so I’ll try switching back, just for a post.

Scrambled eggs

So. Scrambled eggs. Eggs are a basic food that I eat a lot, as do my wife and my daughter. It gives me pleasure to make them well. As we’ve established, I’m a product manager looking for small, hands-on and creative outlets in my real life. There’s no ‘perfect way to cook eggs’, that’s clickbait. But there is a way that suits you and brings you a moment of enjoyment. And I’ve found that for me and my little family.

I prefer scrambled eggs that retain a ‘custard’ type of texture. Creamy and loose. There’s lots of recipes for this kind of scrambled egg all over the place. I’ve found the highest-ranking recipes are often from professional cooks. But cooking in a commercial kitchen is very different to cooking at home. If you’re running a commercial kitchen you have to focus on the speed and consistency needed to make dozens, maybe hundreds of dishes per meal time. So the recipes I’ve seen for loose, creamy scrambled eggs with a touch of the custard about them normally involve breaking and beating the eggs before putting them in the pan. They involve a lot of salt and butter to give the right taste. And they involve a lot of frantic mixing in the pan over a medium to high heat.

However, I don’t want to add a lot of butter and salt to my eggs at home. Salt’s not great for me as a man in my 40s who could stand to lower my blood pressure. And now I’m cooking for 3 of us. I don’t want to add loads of salt and butter to my daughter and wife’s diet either. So I’ve removed elements over the years, lowered the heat, slowed things down . . . and been surprised that I still get good results. Nowadays, I’d say I get better results without the salt and butter. Earlier this year I watched this video on Youtube called Gordon Ramsay vs Marco Pierre White Scrambled Eggs Battle. and it all made sense. Gordon Ramsay makes a variation of the standard creamy scrambled eggs recipe I’ve seen a lot (whisk loads, add things like salt, butter, etc), which I can imagine working in a commercial kitchen for reasons of speed and consistency. But Marco Pierre White cooks like he’s at home. And uses that to remove lots of typical ingredients and replace them with one: time. He takes his time. He cracks his eggs into the pan, over a low heat, and mixes them in the pan. He mixes them slowly. There’s no whisking. There’s little added. Using a low heat. Mixing constantly but gently. And taking time. These things naturally create loose, creamy eggs with a touch of the custard about them. Salt, butter and whisking aren’t required if you take a little more time. I’d gotten somewhere close to Marco’s approach via trial and error but learned several tips from that video that improved my eggs, tweaked a little for my own preferences, and now my method for scrambling eggs is as follows:

For kit, I use a stainless steel pan (because the way I cook scrambled eggs they always stick a little and I can scrub stainless steel with impunity), a soft silicone spatula to mix the eggs with, and a pastry brush to coat the pan in oil
To get ready, I spot the pan with a few drops of oil then brush them to coat the pan, trying to use as little oil as possible. I’m aiming to just enjoy the eggs as they are
I use two eggs if I’m making them for myself. I crack them straight into the pan then put the pan on a low heat. Any eggs are nice. If I’ve thought in advance I try and get some nice eggs, especially for weekend breakfast
I break the yolks with the spatula then mix the eggs slowly in the pan, continuing to do this until they’re starting to have the consistency I want for my breakfast
I turn-off the heat when the eggs are nearly how I want them, using the residual heat to finish them off and reducing the chance that they’ll go over. Once they’re how I like them, serve and eat straight away.

I realise that I’m giving a method for scrambled eggs. Scrambled eggs! And that sounds bonkers. But the general principles of this approach are probably more useful than the specifics:

There’s no such thing as the perfect recipe, that’s clickbait, but there is the recipe that suits you
Recipes from commercial cooks based on meals made in commercial kitchens can be weird in the home
Sometimes at home we have the chance to make basic dishes in a way that commercial kitchens can’t, making them simplier and healthier.

I find it satisfying to head off into the kitchen on a Saturday morning and make us all some scrambled eggs. For my wife, they go with toast and smoked salmon. For my daughter, just with smoked salmon. For me, my scrambled eggs on toast that’s covered in hot sauce. All eaten in our pyjamas at a time when we’d normally be hustling to work or nursery. A celebration of a weekend together.

Notes on the Service Owner role

2022-05-30T00:00:00+00:00

‘So what’s this Service Owner role Scott?’

I’ve been asked this question a lot. I was Head of Product for a large Government department in the UK from 2016-2022 so got a chance to speak with and support a lot of product managers across many Departments and Agencies. A common question during this time was the definition and purpose of the Service Owner role? I’ve worked with lots of Service Owners too and its fair to say the role’s not always 100% clear to people doing it either. The question’s come up again so I’m pulling together what I’ve found out over the years in case it’s of use for current Service Owners trying to figure out a challenging role, and those working with Service Owners and figuring out their relationship with the role.

The reason I’m publishing this post is that Service Owners don’t seem to exist in Local Government (where I’m now working). It’s an area of my time in Central Government that I’m unlikely to use in my new gig. But Service Ownership was a big part of my professional life for a long time so I figured I’d shared my notes before they become so out of date they’re useless. What I’m sharing isn’t presented as the final word on Service Owners. I assume it’s wrong. But I assume it has some value, none the less.

If I were a Civil Servant right now I might feel underappreciated so I’d like to be clear. I support the Service Owner role and the folks who do it - past, present and future.

What did the Service Owner role look like 2020-21?

2020 saw me on shared parental leave for most of the year. I worked for a total of 4 months and, rather than dipping in and out of being Head of Product, my boss supported me to lead short projects instead. One of these was supporting a Service Owner community of practice. As part of that I did what I always do: spoke with colleagues across Government to see what people smarter than me had already figured out. I spoke with 7 organisations (6 Departments and 1 Agency) in 2020 and early 2021. Here’s a summary of my notes.

Firstly, Service Owner is not pervasive across all Government organisations. Two of the organisations had decided not to use the role. Looking at my notes now, what stands-out is that both organisations had invested heavily in their value proposition, positioning in the organisation, relationship management and commissioning processes. And both organisations had empowered Lead Product Manager and Head of Product roles at Grade 6 or Senior Civil Servant (SCS)
Now let’s look at the remaining 5 organisations. 1 of them had Service Owners but the role sat outside the Digital function. Service Owners sat in ‘the business’ with responsibility across policy, operations and technology. Digital supported the definition fo the role and recruitment. Digital skills were important for these Service Owners, as was the ability to work closely with Digital. My notes are unclear of the seniority of the role, I’d guess at least Grade 6 but might have been SCS
Of the remaining 4 organisations, 1 of them had a Service Owner role within Digital that was responsible across policy, operations and technology. They were officially within the Digital function. The role was SCS
Of the remaining 3 organisations, all had Service Owner representing a particular perspective and pitched at Grade 7 or Grade 6. In one case the role described someone from Policy, representing the policy-intent behind the work. In the other two cases the role described someone from an IT perspective, often representing a large programme, large contract or corporate function.

I can’t see clear themes that provide a unifying definition of the Service Owner role. The main theme I see is the variability of the role (even sometimes within the same organisation). So the main conclusion I can draw is the simultaneous challenge and opportunity of having a specialist, Digital role in the leadership space with a great deal of flexibility relative to many of the other specialist, Digital roles.

2016: the intent behind the role

The role of ‘Service Owner’ was designed and defined in 2016 as part of the Digital, Data and Technology Profession Capability Framework. I was in the room during the session’s where it was created (even contributing to it, to a limited extent) so can share my take on the intent behind the role. I prefer pragmatism over purism so don’t propose that the role in 2022 be judged by how well it fulfils the original intent behind it. But I do propose that it’s useful to know the original intent behind the role. Zoe Gould has already shared her perspective on the original intent behind the role, I’ll add my perspective.

My understanding of the context

2016 and the Cabinet Office was looking to define digital specialist roles in Government in order to bolster a case to the Treasury for market-competitive pay for these digital specialist roles. A management consultancy (EY?) led the overall project with Cabinet Office staff from GDS supporting/leading working groups for each of the job families. Delivery management, product management and service ownership were grouped as a job family and a bunch of us ended up in 5-10 all-day workshops in the latter half of 2016 where the roles were drafted. Grade 7 and Grade 6 specialist, digital roles were within scope. SCS roles were outside of scope.

My understanding of the intent behind the role

Key things that’ve stuck with me:

Someone with responsibility for the overall impact of an end-to-end public service
. . . and so needed to be an SCS role capable of providing influence and constructive challenge up to and including Ministerial-level
Responsible for policy, operations, and technology across a public service
To help differentiate from the IT Service Manager role.

Hindsight

A reflection I can make with the benefit of hindsight: back in 2016, Service Owner was an aspirational role. It didn’t exist in ‘the market place’, so you couldn’t go and see how others were describing it (unlike something like product management). And it didn’t really exist in Government either, not in the way it was described. Even the role title of ‘Service Owner’ was created from scratch as part of our workshops, with the official title changing several times during this time. This was introducing a new role intended to be responsible for an entire, end-to-end service. And this intent was maybe at odds with the official scope of only Grade 7 and Grade 6 professions, mainly describing specialist, Digital roles that already existed in the market place? Once again, we see the challenge and opportunity of a role that’s looser and more at the boundary of Digital than some of the other roles.

Service Owner pre-history

The DDaT Capability Framework, including the Service Owner role, began implementation in 2017. Prior to this the Service Owner role did not exist. The label of ‘Service Owner’ was created during the DDaT development process in 2016. My insights from this pre-history of the role are limited so I’ll share what I’ve got, acknowledge my limits, and suggest there are others with way more valuable perspective.

My own, limited experience of the role runs from 2015-2017. The Department I worked at had 4-5 ‘Service Managers’, SCS roles responsible for a unit of the overall Digital work. I guess a label that might better describe the responsibilities of their role might be ‘Head of In-House Software for [name of an Agency or the main Dept.]’. Each was doing pioneering work to introduce in-house software development, user-centred design and long-lived, multidisciplinary teams to an area of Government. And Service Manager was a fine-enough label to describe this. However, what mergers between ‘Digital’ and ‘IT’ started to demonstrate was that ‘Service Manager’ (specifically IT Service Manager) was a role that already existed within IT, and had existed for quite some time. Digital using the same title to describe something different enough to warrant its own title cause enough confusion to warrant it forming part of the intent behind the Service Owner role.

Personal takes

Notes to this point are fairly ‘factual’. They’re notes on events or personal experiences with little conjecture. If that’s all you’re looking for then stop here before I get a little more chin-stroking and offer some personal-takes.

So my overall experience of the Service Owner role involves:

Working with the role (and early version of the role) from 2015-2022
Hearing the intent behind the role (and limited contribution to the role) in 2016
Sporadic contact with Service Owners cross government via Service assessments (I was a prolific Lead Assessor for GDS 2016-2019, assessments often include a Service Owner)
Supported a Service Owner community of practice in 2020.

The most consistent thing that strikes me about the role of Service Owner is it sometimes operates at the boundaries of ‘Digital’ and acts as a metaphor for these boundaries.

Digital units in Government have different scopes from one Department to the next. My take is that some are based in IT, offering core IT services alongside user-centred, in-house software and a limited line in service design consultancy. Some are mainly around broad service design, with some in-house software and limited remit in core IT. There’s loads of shades in between and I’m certain loads I’ve missed out. The point is that, whatever the intent behind the Service Owner role, we all work in the space we’ve got to play with.

One aspect of this is language. Or speaking different languages, to be more specific. Digital is increasingly a space where user-centred design and core IT works together. And they use different languages to describe the way they work. In UCD, we commonly expect ‘service’ to describe and end-to-end public service and everything needed to run it. In IT, we commonly expect ‘service’ to describe an IT system. Merging the two ways of working makes sense but it’s fair to say that there’s not yet a common terminology. Service Owner is one of the roles that might find itself in the middle of this.

There’s something interesting about the DDaT framework too. I think I’ve seen an issue where we treat it as though it captures all the roles needed to successfully improve outcomes of users of public services. It doesn’t. There are lots of roles it doesn’t cover. It’s intent was just to cover specialist, digital roles that exist in the market place already. My take is that it’s skewed towards the roles needed at the beginning of the lifecycle, roles needed for development and doesn’t cover the roles needed later on in the lifecycle to increase the use of a thing (communication, engagement, training, supporting, user community management, etc). It also doesn’t cover the breadth of leadership and management roles needed to run Digital units. I think we over-use the DDaT framework and forget that we can use roles outside it that’re equally valuable and essential to our success. And, as a result of this, some roles end-up being used to describe lots of skills at the boundaries of Digital that are essential but sometimes overlooked or underrepresented. Of these, I think the most underrepresented but most valuable thing missing can be relationship management (between Digital units and their internal clients, collaborators and supporters). My hunch is that this invisible but critical work can often be a large part of the Service Owner role.

My final, personal take, is to share my hunch about the closest examples of fulfilling the original intent behind the role. I saw a job-ad for a Service Owner in Defra Digital back in early 2021 and, from the outside looking in, it seemed to be an SCS role based in Digital with responsibility across policy, operations and technology. I have no insights beyond the job ad and don’t wish to speak on behalf of the Department itself for how the role is used in mid-2022. But back at the beginning of last year the role description peaked my interest and that of colleagues in the Service Owner space in Government. More generally, my last take is that CEOs of Government agencies may fulfil the intent behind the Service Owner role without necessarily having explicit links with the role?

A conclusion of sorts

If I have something like a conclusion, it’s that Service Owner isn’t a role I’ve seen outside Central Government. But I recognise and respect that Central Government has characteristics that make it complex, including but not limited to the need to serve everyone and the scale of work that goes along with this. Digital is one small part of the large, complex thing that is Government and the closer we get to the boundaries of Digital the messier things become. Digital isn’t a fixed thing, it doesn’t mean exactly the same thing from one Dept to another. But Digital always has internal and external boundaries that can always be navigated by the more clearly defined roles in the DDaT framework. My take is that Service Owner might be a role that works on these boundaries, filling gaps in the messiest spaces. Their skills and work is valuable and essential. There’s the possibility that there may be better, more accurate ways to described this valuable work - in some cases, other roles in the DDaT framework like Programme Delivery Manager, or IT Service Manager in other cases roles not on the DDaT framework like ‘Head of Digital’ or ‘Relationship Manager’? I guess the thing for the current and next generation of folks to figure out is the value of a flexible role that can mean different things and operate on boundaries versus the value of a consistent role and a shared profession?

I’m at least 6-months out of date in my experiences of the Service Owner role and figured this is the last time I had to share them before they’re so old as to be useless. I think the a limit to this post is I’m talking about Service Ownership across government rather than what it looks like in a single Department. I’d love to read this deep-dive into a the role in a single organisation. The genesis of this post was a Tweet asking if any Depts had shared their approach to Service Ownership, and I’d love to see a deep-dive into what it looks like in a single space. My sense is that it could bring the role to life in a way that my post (covering multiple Depts and multiple years) can’t really do.

The next ten-years of digital government

2022-03-03T00:00:00+00:00

Organisations designed as well as products

Introduction

Digital Government is (kind of) 10-years old.* What will the next 10-years look like?

Last year one of the first-gen GDS folk led a project at my old organisation, I got a chance to work with them as part of this. In our final meetup I asked for any big trends they’d spotted and they said something like ‘figuring out what the next 10 years look like for Digital Government . . . some of the big companies give the impression they can do the Digital thing as well as the in-house teams, they’re competitors . . . what does that mean for the in-house Digital teams?’. Just a few days ago GDS took-on Deloitte to develop help develop an identity app. There are good and sensible reasons for this, as shared by Will Myddleton. There are good reasons for choosing suppliers to do ‘Digital’ work. I’m not a fundamentalist who believes everything should be done in house. I’m a pragmatist. Anecdotally, I’m seeing a growing appetite to work with suppliers on ‘Digital delivery’. In-house teams need to accept this and figure out what it means for them. What’s their unique selling point versus external competitors? And what does the next 10-years look like?

I was going to use this question - ‘what’s the next 10-years of Digital Government?’ - to help me and fellow Heads of Profession build our long-term vision. I’ve now left my organisation so we won’t get a chance to do this together. But it remains an interesting challenge in product-positioning. So after the first 10-years where ‘delivery was the strategy’, here’s why I hope that the next 10-years is about designing our organisations as well as our products.

Note: * It’s not as neat as being 10-years old. GDS was 10-years old last year but ‘Digital Government’ work began a couple of years before GDS officially appeared and you could argue that the ground work started being done as early as 2005-6. But that’s not a pithy opener for a blog post so you can see why I went with ‘10-years old’. The general point remains the same: Digital Government is getting old and hitting its teenage years.

Pioneering to settling

You’ve probably heard someone talk about pioneers, setters and town planners. I can be a contrarian, so I avoided using it for ages. But, revisiting it a couple of years ago, I was struck by how well it described patterns I’d been seeing. I got over my contrary nature and started using it.

‘Pioneers settlers town planners’ is the work of Simon Wardley. A summary of the model can be found on Wardleypedia.org. As Simon himself would say, it’s a model and it’s wrong but it still has value. So here’s a version I’ve simplified and tweaked for the purposes of this post.

Pioneers	Settlers	Town planners
Creates new technology	Grows use of products	Increases efficiency
Uses agile and components	Uses ecosystems	Uses six sigma
Accepts uncertainty	Accepts constant improvement	Accepts analytical decision-making
Deals with the new and poorly understood	Deals with increasing education	Deals with standardisation

Note: the terms pioneer and settler both have problematic connotations and I’ve seen Simon say online that he’d use different terms if creating the concept today and is, I think, open to suggestions for better terms.

Ground work

Preparation for Digital Government began during Tony Blair’s third Ministry (2005-2007), led by the Cabinet Office. Gus O’Donnell, the Cabinet Secretary at the time, regularly spoke about about two things: managing risk (instead of trying to avoid it) and customer insights. The Cabinet Office published a working paper called ‘Customer insight in public services - “A Primer”’ in 2006.It included guidance on using tools like customer journey mapping to improve services. The front page is a quote from Gus O’Donnell:

“We must be relentlessly customer-focused. Many people want a single point of contact for a range of services. The public are not interested in whether their needs are met by Department X or Agency Y, they just want a good, joined-up service where X and Y talk to each other and share information the public have provided. We should strive to meet this demand.”

First-wave Digital Government: Pioneering

First 10-years belonged to pioneers

It’s not a stretch to see the first 10-years or so of Digital Government as the age of pioneers. Simply existing in the first place was pioneering. Delivery of the initial 25 exemplars was pioneering work. The introduction of components following the ‘Government as a Platform’ movement was pioneering work. Every Government organisation with a Digital portfolio has done pioneering work over the last few years that adds-up to exciting change in how public services are delivered in the UK.

Components and trust

Components are interesting to me. This is where I joined the Digital Government work. I joined in 2015 to help the Ministry of Justice create what’s now called the ‘Platforms and Architecture’ business unit. I also got to work with, share with and learn from other Government Departments like Home Office and HMRC who were starting similar work around the same time. And GDS, where there was a lot of collaboration with the GaaP folks. I even got to lead the assessment of some of the early GaaP Alphas. I came to realise a couple of important things back in 2015:

It’s easy to think of components as ‘technical products’ and skip user-centred design. I don’t agree with this.The root of the word ‘technical’ is ‘technique’. What people mean when they say ‘technical product’ is ‘a product with techniques I don’t understand’. They’re staff-facing products. As staff-facing products they need to be well designed in order to be adopted.
The value proposition for components is trust. We all have a tendency towards exceptionalism. We believe we’re doing something so unique it requires a totally bespoke approach. The truth is we’re often more similar than we are different. Components take a custom activity that used to be in someone’s control. Removes that control. And tells people they’re not as special as they thought. That requires a lot of trust.

Pioneering and settling happen at the same time

More recently I’ve realised that ‘pioneering’, ‘settling’ and ‘town-planning’ are not discrete, sequential stages. Rather, they all need to start at the same time because they each take longer than the last. Each phase happens at a different speed because each phase is harder than the last. I came to realise that ‘settling’ is where trust is built across the organisation. This trust is a critical dependency for adoption of components. And maybe, the pioneering work has become a means to an end. The real goal, right now, is to focus on settling: designing the ecosystem in which we operate as well as we designed our pioneering products.

Second-wave Digital Government: Settling

I saw a Tweet a few months ago. It said something like: ‘the must-have skills in the 2010s was software development, in the 2020s it’s going to be community management’. I think there’s truth in this. Viewed from the perspective of the Civil Service, ‘Digital’ has become part of the furniture. No longer are people excited by the simple act of creation of in-house software. Now it needs to actually be used, at scale. Fundamentally, there’s a switch to return on investment (or benefits realisation in the language of Government). There’s an increasing need to (i) seek the best opportunities for benefits realisation and (ii) focus on the mature phase of the product lifecycle (or ‘Live’ in the language of Government). Both of these things need us to be as interested in our organisations as we are in the problems we’re solving for our users. And both of these things require us to recognise that the software is (usually) not our product.

If we want to grow the use of our products and develop new opportunities we need to invest in understanding the ecosystem we’re a part of. We need to switch to constant improvement of mature products. And we need to deal with the increasing need to communicate and educate. We’ve always had to do these things but, in my experience, it’s always been invisible work. Activity to understand our organisation or to develop our culture has largely been invisible from portfolios that tend to favour our ‘official’ class of work: reporting delivery of IT assignments alongside budget lines. In many instances we’ve been rewiring the house around us in order to achieve relatively simply ‘digital delivery’ but this organisational change doesn’t appear on any sprint backlogs or roadmaps.

Making this work visible, investing in it and setting explicit goals is the stuff of the second wave of Digital Government. Working on organisational culture can lead to spurious workshops to help define ‘what even is culture?’. Nobody wants that. So allow me to recommend Simon Wardley once more. Simon’s provided a starting point for thinking about culture, called ‘doctrine pattern’. Here’s a helpful summary in table form. It breaks culture into phases with clear elements. As I said earlier, it’s a model and it’s wrong but it still has value. This gives a day-1 starting point. The next 10-years needs us to introduce an explicit-class of work focussed on how we work within our ecosystem and how we interact with users of our mature products. We need to invest in designing our organisation and its culture as well as we design our products. And Simon’s doctrine pattern gives us something to help. We’re starting in the middle, as ever. We’ve been doing this for ages but it’s been treated as invisible work. Now’s a chance to make it visible, so we can grow use of our mature products and develop new opportunities. The pioneering work needs to continue, this isn’t about stopping that. This is about recognising the need to start investing as much time and effort in ‘settling’, which requires transformation of relationships to be on equal-footing with transformation of technology. If the first 10-years was about introducing the Lean Startup to Government then the next 10-years is about introducing the Lean Enterprise to Government. The Lean Enterprise is about how to run an entire organisation that’s designed to work as well as an individual team using Lean Startup.

An example

I’ve just left the Ministry of Justice where I worked in the ‘digital and technology function’. This Digital and Technology Function is over 1,000 people. The Digital half is separated into a unit that support the MOJ itself, alongside a unit each for Criminal Injury Compensation Authority,,Legal Aid Agency, Office of the Public Guardian, Prisons and Probation. There’s also a unit for shared platforms. Collectively as MOJ Digital and Technology, these units are working to 40 separate strategies and supporting over 80,000 staff alongside millions of public users.

Communities of practice were introduced into this mix. If ‘what’ we need to achieve is set by the senior leadership teams then professions are ‘how’ the goals are achieved. This ‘matrix management’ in action. Professional communities of practice bridge across organisational silos. Silos can exist at the scale of individual teams right up to entire divisions of an organisation. Digital, data and technology professions cut across these silos and help us to work in the larger ecosystem of our organisation.

Except when they become silos themselves. We realised that professional communities in government had defined ourselves to ourselves and for ourselves. But we’d forgotten to define how we work together in teams to get things done. It’s hard to figure out how our specialist roles work together in multi-disciplinary product teams. We need to figure out how we work together. The unit of delivery is the team, not the profession.

It became clear that professional communities of practice are just one of the features needed for us to design our organisation as well as our products. Communities of practice need to sit with other types of communities, knowledge management, curation and standards.

Communities. Communities of practice within professions are not enough. We need other communities that cut across professional boundaries. Like communities of interest. For example, somewhere that anyone working on a Discovery can come together, share and learn from each other. And communities of action. For example, somewhere for people to come together and improve knowledge management.
Knowledge. Communities generate knowledge. Usefully storing knowledge is hard. There’s work to use common tools, to have common taxonomies, to keep the information up to date and useable. The most radical act of innovation that many large organisation could make is to invest in a Content Designer and Librarian.
Curation. “We consume information recreationally, not as a way to achieve our goals”, to quote Sari Azout. I spent years running my profession’s product management handbook but it was already being forgotten after a few months away on shared parental leave.Knowledge needs to be curated and regularly put in front of us, discussed and explained, if we’re to actually use it. Communities, 1:1s, coaching and mentoring are all great places for knowledge to be curated and brought to life.
Standards. Standards are the ‘so what’ to this whole thing. Standards reward us for starting from what’s already been figured out. And provide consequences for needlessly reinventing the wheel. They frame knowledge and incentivise its curationt. When standards truly matter, an organisation can solve problems once and share with everyone.

In 2021 my role was leading the ‘user-centred professions’, 350+ people across business analysis, content, delivery management, design, product management and user research. Many organisations solve the same problems again and again, in silo after silo, in generation after generation of the workforce. This is the definition of inertia. My hypothesis was that we need to design our bit of the organisation as well as we define our products. Initially focussing on how we work together in teams: if we tried designing our relationships with each other as well as we designed our products (using communities, knowledge, curation and standards) then we could expect to see common problems (like how we really work together in teams) be solved once, for all. For me, innovation is when we solve new problems. This whole thing was about reconfiguring ourselves as a component. A knowledge component. Which is pioneering work. But realising that we can only grow our internal market by simultaneously settling, building and understanding ecosystems. Designing our bit of the organisation as well as we design our products.

Positioning in-house teams

I think we may have to accept that, for all sorts of reasons, some of the pioneering work of building bespoke software to run steps of public services may be done by suppliers. I’m not building the case for this or making a prediction, just naming something I’m seeing.

But there’s a saying, ‘you ship your org. chart’. I think in-house teams have a unique advantage in a couple of spaces at opposite ends of the product lifecycle: (i) generating opportunities and (ii) settler work of developing organisational ecosystems needed for constant improvement.

Generating opportunities. ‘Discovery’ and ‘Alpha’ are simply two phases of developing opportunities. They require huge situational awareness in order to be done well. If you have one two teams with roughly equal skills but one of them has been embedded in the organisation for 1-2 years then it will out perform a comparable team new to the organisation. This is not to say that external teams can’t do Discover and Alpha, they can. And this is not to say that every internal team can do Discover and Alpha well, as that’s not true. If the team is new to each other and/or the team members are new to the organisation or domain then competitive edge is diminished. But all things being even - internal digital teams have the competitive edge when it comes to generating opportunities. If the opportunity is well-developed by an internal team then a supplier can legitimately be provided with a good brief and setup for success for a private beta where they are building software through build-test-learn iterative cycles. Once again, I’m now trying to build a case that this should happen just being pragmatic and suggesting refinement of something I see happen already.
Settling. Understanding and developing an organisation, designing it as well as we design our products, is always going to be best-led by the organisation itself. Transforming relationships requires trust and that trust has to be built internally.

If we can be a little looser about all software having to be built in-house and recognise that in-house teams no longer have the exclusive competitive advantage here, it may free us up to focus where we do have our competitive advantage.

Reflection

I almost didn’t write this post. It’s sketchy. It’s emergent thinking. It needs challenge and refinement. The story around it needs to be clearer. This all takes time that I don’t have right now, leaving this post imperfect. Then I thought, that’s the perfect time to share a sketch - to test it against reality now, learn and improve. I’ve written this with a tight timebox and stream of consciousness. Apologies if you need to squint a bit to see what I’m trying to share.

Brain-splurge over. Now I can look back and see what stands out to me. Here’s are the main things:

The first 10-years of Digital Government have focussed on pioneering work of creating in-house software and components
The ‘settler’ activity of understanding and developing the larger ecosystem has always happened alongside but has been invisible and unofficial work
In-house Digital teams no longer have such a clear competitive advantage when it comes to software development
As our products become more mature, community management starts to overtake software development as a the critical skill
. . . so Digital Government needs to focus on settler work in its next 10-years, eventually investing as much money in improvement of elements of the doctrine pattern as it does in the development of technology
In short, it’s about designing our organisations as well as we design our products.

For what it’s worth, my instinct is that the NHS might be the place that leads (by doing) the settler phase over the next 10-years. Showing by doing. The work of the last 2-years during the pandemic, the recent restructuring, and some conversations with people leading this work all make it sound like they’re explicitly investing in the work of the settler phase. Looking closer to my old home, the Office of the Public Guardian is doing this at a smaller scale. Modernising lasting power of attorney is all about Digital, Operations and Policy working together, along with other organisations in the wider sector, to make deep changes for the better.

I’m going to refine my thinking, improving and simplifying it. Hopefully make it less sketchy, better defined. But I hope there’s at least one thing in here already that you recognise or find useful. And I’m interested to know what you see for the next 10-years of digital government.

So you're a Product Manager in Government

2022-02-27T00:00:00+00:00

Here’s a bunch of things I’ve learned about product management in Government over the years. I worked in the UK’s Digital Government from 2015-2022. I joined in the early years and learned a lot from the first generation of folks in the space. Then moved into a Head of Product role and helped shape, define and lead what the profession has come in the years since. This post provides links to posts sharing the main thing’s I’ve learned learned in that time.

What type of product manager are you? This post explains that product management means different things in different places. That’s OK. Just make sure there’s a good fit between how the role’s being used and what the organisation truly needs from the role.

What is product management in Government? This post on the MOJ blog summarises what Government needs from our role and what it looks like along the career pathway. There’s a longer version on my personal blog.

Value. Melissa Perri shared a wine-fuelled Tweet a couple of years ago saying that product management is about outcomes and value more than technology. I totally agree. Here’s my take on why ‘product manager’ is a bit of a rubbish way of describing our role, tbh, and that we’re really value managers. To help with this, I did some digging to figure out some high-level principles and guidance on how to measure the outcomes/value of our products (this definition is used for internal Service Assessment at the Ministry of Justice). I worked with a Cabinet Office Economic Analyst in 2018 and contributed to guidance on measuring product benefits.

Product manager role description, skills and career pathway. I co-authored the UK Government’s product management role description back in 2016 along with the other Heads of Product at the time, as part of creating the ‘Digital, Data and Technology Profession Capability Framework’ that’s still in use today. This was pioneering work and created one of the largest-scale, shared understanding and use of a role I’ve experienced. It was imperfect from the start and is more imperfect today. The Lead Product Manager role in particular leaves a lot of room for improvement, with the Lead PM description from the London Office of Technology & Innovation (originally developed by Royal Borough of Greenwich) looking better. But it remains valuable as an engine for open and fair recruitment, development and progression.

Product management handbook. I started managing other PMs back in 2015 and found myself repeatedly sharing the same blog posts and books. I started picking-up the Head of Product role in 2016 so pulled together links to these blogs/books together for the profession. 2017 and I got the Head of Product role permanently and decided to switch the links to a handbook with more explanation, and more tweaks to make it relevant for Government. I’ve updated the handbook yearly since, publishing this open version in 2018. This white label handbook remains a great tool for product managers. And it’d benefit from updates that reflect that last couple of years of developments in the world of product management. The handbook is published on GitHub where anyone can contribute. Here are some individual posts that expand on sections of the handbook:

‘The Lean Startup’ - notes for product managers
The Agile Manifesto for public services
Using the Strategyzer business model canvas
Product roadmaps in 5 easy pieces
Deciding on priorities - I contributed to this guidance on gov.uk that was intended to break the curse of MoSCoW prioritisation
Ethical product management
Why I’m not frustrated with the discovery/alpha/beta/live lifecycle phases
Exploration (previously known as ‘pre-discovery’) at the MOJ
Discovery in Government and 10 experiments you can try to improve your Discovery.

‘Technical’ products. I started off at as ‘hands-on’ product manager, helping to form a Platforms department. I learned a lot here. Two posts about this time are ‘The five stages of applying the Service Standard to technical stuff’ and ‘5 tips for successful internal platforms’.

Product leadership. Finally, if you’re looking to make the move from product management to product leadership then there’s ‘how I developed as a product leader’, ‘5 product management hacks for product leaders’, and ‘lessons learned from six-years leading a product management community of practice’.

All of the above is is imperfect. It has value but you can totally take it and improve it. On which note, there’s a lot of people within the Government product management community doing great things. Three that stand out to me are:

Simon Manby is a senior product manager modernising lasting power of attorney by day and running cross-government product meetups (like this one) by night, they’re well-worth joining. Here are Simon’s top 5 tips for running remote meetups for product managers
Debbie Blanchard runs a cross-government matching service for product managers looking for peer mentoring
Rose Waite created a self-managed learning course called ‘cross-government introduction to agile’. Rose has previously shared tips on how to setup and maintain your own product community.

I’ve definitely missed people from this list, please share anyone you’ve seen going out of their way to help the cross-government product community.

Digital Folk Tales

2022-02-10T00:00:00+00:00

Winging it

‘Welcome to the team - now you’ll realise we’re all winging it!’

I joined the Ministry of Justice’s Digital team in August 2015 and was greeted with that message by Tom Dolan. Tom was on my interview panel and a few months later when I finally joined he spotted me on my first day. It was a comforting message. We were all there because of the pioneering, world-leading work going on. And - everyone was winging it. Based on huge and varied collective experience. But winging it. I think that was true right across Digital Government. And I think it’s as true today as it was then.

Digital Government is the home of pioneering, world leading work. And if it sometimes feels a little constrictive or a little prescriptive? That’s because it’s the result of people just like you who were winging it. There’s an unwritten folk history to the Digital work in Government. There’s power in knowing some of the intent and messy reality behind stuff that has become ‘big’ and ‘official’. So here’s an anthology of Digital folk tales from my experience of some of that big and official stuff. These are personal stories. Don’t trust the teller, trust the tale. Let’s assume that I’ve got things wrong and am writing from my own subjective and limited perspective. But the sentiment is true in each case: great work was done, it was valuable, people were winging it and you can improve it.

Tweaking the Service Standard

The Service Standard is a big reason why I joined Digital Government. I actually worked in ‘the normal’ Civil Service from 2006-2010 and partly left because I was excited about this agile, customer-centred way of working thing and couldn’t find a way to make it stick in my Civil Service roles.

I moved over to non-profit and social enterprise world where I could use this approach. ‘The Lean Startup’ was published a year later in 2011 and it pulled together this way of working in a smart, useable way. Me and my CEO were excited by it - it’s the subject of my first ever blog post back in 2012. We successfully pitched for funding from the Esmée Fairbairn Foundation to adapt if for the charity/non-profit/social enterprise space. But someone had beat us to it. We started to realise that the folks at the Government Digital Service were already doing something that largely fulfilled our intent. So we decided to pivot. Use the emergent Service Standard, Design Principles and Service Manual coming from them. And instead use our funding for a pot of discoveries to find the most valuable problems we could feasibly solve. We used The Lean Startup and the Service Standard and the influences on both of them, taking the bits from each that worked and leaving the bits that didn’t.

I re-joined the Civil Service in 2015 as part of the new Digital tribe. Working on the MOJ’s first platform (the Cloud Platform) I wanted to take a user-centred approach. It’s easy to think of components and platforms as ‘technical products’ but I don’t agree with this. They’re staff-facing products. The root of the word ‘technical’ is ‘technique’. What people mean when they say ‘technical product’ is ‘a product with techniques I don’t understand’. So, long story short: it’s a staff-facing product, built by WebOps engineers for Developers, who are users and deserve a user-centred approach. Me and the team elect to use the Service Standard in order to help with this. But the Service Standard doesn’t work ‘as is’ so we tweak each point. We never lower the bar. But we totally allow ourselves to make it work for the real world that we’re working in. We allow ourselves to adapt each point by returning to the original intent and figuring out what that means for a staff-facing product consisting of mainly open-source tooling operating on top of cloud hosting. This approach works.

If The Lean Startup is behind the Service Standard, what’s behind The Lean Startup? Eric Ries, the author, is explicit on this. tates that it is based on:

Lean manufacturing - how to build things efficiently, based on decades of good practice in the manufacturing sector (particularly identified with Toyota)
Design thinking - a set of tools and methods to help organisations design products based on the needs of users (this had particular influence on our phases of agile delivery; many people first engaged with this via the Institute of Design at Stanford University, particularly their famous Design Thinking Bootleg
Customer development - builds on the premise that when we start something new we have a lot of untested assumptions. Therefore we need to avoid doing anything based on these assumptions. Rather, we must do relevant and focused research before going ahead and building anything (this had particular influence on our discovery phase); the book ‘The Four Steps to Epiphany’ by Steven Blank helped shape customer development
Agile development - an adaptive approach to software development that recognises that user needs and software itself evolves over time through the collaborative efforts of multidisciplinary teams working with (and based on insights from) their users; the Agile Manifesto for Software Development is the driving force behind this.

We can adapt the Service Standard to our context as long as we remain true to its influences and intent. The Service Standard represents pioneering, world-leading work. It’s valuable, people were winging it and you can improve it.

The Five-Year Itch

It feels a bit like everyone’s leaving Digital Government right now doesn’t it? Some wag on Twitter suggested we started Digital Transfer News to share completed signings, deals and gossip :) Don’t worry, I think this happens every five years and everything will be OK.

Monday 15th August was my first day in Digital Government. I’d been attracted by the pioneering work of the Government Digital Service. And the leadership of folks like Mike Bracken and Tom Loosemore who I’d heard talking on the digital meetup circuit.

Friday 12th August was when I read an article in The Guardian which asked ‘Why are senior staff fleeing the Government Digital Service?’. A lot of people left Digital Government at the tail-end of 2015 and into 2016. This had an impact on the mood. On a personal level I was thinking “oh no, have I joined too late just as it’s all coming to an end?’.

The answer was ‘no’. People change. Digital moves on. That last big change was around the five-year mark (ish) in the official history of Digital Government. We’ve hit the ten-year mark and I see something similar happening now, with lots of people leaving. But what I recognise is this also means that lots of people are moving up. And lots of people are moving in. Digital Government represents pioneering, world-leading work. It’s valuable, people are winging it and you can improve it.

A Digital-rose by any other name would smell as sweet

The official history of UK’s Digital Government movement is pretty well documented. There’s things like ‘A GDS Story’ that stretch back to Martha Lane Fox’s pioneering and now famous report on the future of Directgov in 2010.

But an organisation as big as the Civil Service takes a while to change. There’s a prehistory to Digital in Government. And I glimpsed bits of it whilst working in ‘the normal’ Civil Service from 2006-2010. I periodically heard Gus O’Donnell, the Cabinet Secretary at the time, talk about two things: managing risk (instead of trying to avoid it) and customer insights. In 2006 I found a Cabinet Office working paper called ‘Customer insight in public services - “A Primer”’. I still have a copy. The front page is a quote from Gus O’Donnell:

It included guidance on using tools like customer journey mapping to improve services. This was exciting for me. I wrote a briefing paper for my senior leadership team and used it to make space for customer-journey maps to improve my service (provision of skills tests for trainee-teachers).

I wasn’t alone in this. I connected with lots of people in a similar headspace who were doing similar things, trying to improve what they were working on in whatever way they could. They were often successful despite odds stacked against them. But were usually so modest that you’d never know about it.

I share this because the Civil Service is massive and our Digital is a little bit of it. There’s some stuff that we’ve packaged-up and called Digital and it’s officially ‘ours’. But in reality it can’t happen without our colleagues and it’s unofficially happening all over the place. Digital Government has done and continues to do pioneering, world-leading work. It’s valuable, people are winging it and it can be improved by our awesome colleagues around the Civil Service.

‘I never had a roadmap’

Digital Government has a good reputation. It’s a space that people want to work. And it can be intimidating. I remember seeing blog posts talking about these seemingly huge teams. Every team has a dedicated researcher! Back in early 2010s, this wasn’t true for me. Or for a lot of my peers outside Government Digital. I’m unsure if it’s true for lots of people in the 2020s to be honest. This was one thing among many that made me think I didn’t have the experience needed to apply for jobs here.

Product management is my particular specialism. I’d see a post about the roadmap for GOV.UK and think ‘eesh, I’ve never done a roadmap that massive, maybe I’m not what these people need?’. I spoke to some folks who helped me gain the confidence to apply for a role and I ended up the other side of the fence. And do you know what I learned from those first product managers I spoke with? Say it with me now: ‘we were winging it’. Based on huge, collecting experience. But winging it. Two people, independent of each other, said something like ‘I never had a roadmap in the early days’. Delivery was the strategy. The initial 25 exemplars represent clear product visions. The problem, the solution, and the goals were agreed at a very high-level and shared very widely. Collectively there was a wealth of experience. The folks I spoke with said that, at least in the early days, they cracked-on. Lots of the things we agonise over today, like roadmapping, were not a priority in the early years. I bet this is true of most of the professions. Those early folks were pioneers. They did amazing work. Many of them are disarmingly honest about the fact that they were winging it. There was an enormous amount of reflection and improvement.

Now we have the Digital, Data and Technology Capability Framework. The product manager role description is the one I know the best. Sat on gov.uk it looks official, like it’s always been there. The truth is that it’s the result of 5-10 of us working together sporadically in the second-half of 2016. The Heads of Product of the time worked with Cabinet Office in several all-day workshops. We worked through things like wether to call the role ‘product owner’ or ‘product manager’. We agreed that ‘product owner’ is a specific member of a team within a single methodology. It’s a good way of describing product management tactics. But isn’t the whole role of product manager as it doesn’t cover strategy or vision. So ‘product manager’ became the role and product ownership became one of the skills for the role. Blog posts from 2017 show Ross Ferguson (Head of Product at GDS at the time) and Zoe Gould (Head of Product at DWP at the time) talking about the thinking behind this and some of the impact it had. Looking at the role description in 2022 it’s hard to get a sense of why this decision - and many like it - were made.

Context is important too. Zooming back in time to 2016: having specialist digital roles officially within the Civil Service was a big deal. Particularly in a way that allowed for specialist pay. Positioning these specialist roles within leadership teams or within the Senior Civil Service would have been an even bigger deal . . . and was not our priority. Senior Civil Service roles were out of scope. Simply having ‘Lead’ and ‘Head of’ role descriptions was a big deal and we were conservative with the detail of those roles by today’s standards. It didn’t take long for them to feel constraining. ‘Lead’ and ‘Head of’ roles increasingly stepped out of roles framed as ‘people managers’. And increasingly stepped into active membership of senior management teams. The Lead Product Manager role description written by the Royal Borough of Greenwich Borough in 2021 looks to me like a more confident description of the Lead Product Manager role than we created in Government back in 2016.

The thinking done by a load of us back in 2016 to create the Digital, Data and Technology Capability Framework was pioneering work. It’s one of the things I’m most proud of. It helped create the clearest sense of the role I’ve experienced in any prior organisation or sector. Several folks who’ve left for other sectors have said things like ‘I didn’t realise how good we had it, my new organisation doesn’t understand the role’. The framework is valuable. And the authors were all winging it. Based on huge collective experience. But winging it.

If you’re an existing Civil Servant working in a ‘DDaT role’ it’s totally OK for you to tweak the detail to make it work for your. If something doesn’t fit there’s a good chance it’s down to a quirk of a working group back in 2016. Or simply a case that the world has moved on. I’ve never known GDS (now CDDO) be anything other than supportive of localised tweaks (in this and in all things). If I remain true to the original intent and don’t lower the bar, I’ve always received support from GDS/CDDO.

If you want to work in Digital Government but think you’ve not got what it takes after reading the blog posts or looking at the role descriptions then please remember: we’re all making it up as we go along :) I’ll steal something from Culture Amp to share here: “Research shows that while men apply for jobs when they meet an average of 60% of the criteria, women and other marginalised folks tend to only apply when they check every box”. The Digital Government blog posts and the role description imply a lot of boxes to tick. If you think you have what it takes, but don’t necessarily tick everyone of these boxes, please still give it a try. Digital Government has done and continues to do pioneering, world-leading work. It’s valuable. People are winging it. And you can improve it.

Your turn

I would love to hear Digital folks tales from others. Have you got your own Digital folk tale that puts a human-face on our work? Or have you read a Digital folk take that’s already out there? I’m not looking for iconoclastic exposés. But would love to find descriptions of amazing work that are honest about how messy reality is.

Lessons learned from six-years leading a community of practice

2022-02-06T00:00:00+00:00

There are a bunch of blog posts about building professional communities of practice. They’re often from people who help start the community. Or people that come in and support them for a period of time. I’ve not seen many that cover the history of a community over years.

I re-launched the Ministry Of Justice’s product management community of practice in 2016. It started with 10-12 people and, six-years later, it’s approaching 80 people. The same number of people have come and gone during that time. In 2021 I picked-up leadership across the user-centred, product and delivery professions, increasing my scope to 350+ people across 6 specialisms. Now’s a good time to reflect on what I’ve learned.

This is a post about what it’s like to lead the same community of practice for a long time. It’s the story of what happens as the people change, enthusiasm ebbs and flows and the community grows. Each section could be a post in its own right but I haven’t got the time or patience for that :) So here’s a single, whistle stop post about what it’s like to be six-years deep in a community of practice.

I’ve added a table of contents with links to specific sections so you can pick and choose what to read.

Prologue: The Spotify model (probably) won’t work for you

Part 1: Building a product management commmunity of practice

Foundations: the key elements for a new commmunity of practice
Psychological safety: community leaders need their own safe space
Hands-on anxiety: how to avoid anxiety over not being ‘hands-on’
Sharing leadership: how and why to start sharing leadership activity
Connecting with other community leaders: the value of community leaders working together
Looking across the sectors: the value of learning from other sectors
Distributing leadership: how and when to segment the profession and disitribute leadership
Testing the community: stepping away as a leader to test the profession
From busy to strategic: making space for strategy as a community leader.

Part 2: Building a network of communities

Don’t build new silos: the risk of communities of practice becoming new silos
How to build networks of communities: designing an organisation that can solve problems once and for all, using communities, knowledge, curation and standards.

Epilogue: the three things I’ve learned the hard way

Prologue

It’s ok to start with “the Spotify model” . . . and abandon it

I was hands-on in product management at the MOJ before I became Head of Product. I was responsible for a staff-facing product when I joined in 2015, our ‘Cloud Platform’ for running and changing software. This took (and still takes today) the form of a continuous integration setup built on Amazon Web Services. As part of this I had to centralise the Web Operations Engineers, helping them to switch from a being a lone wolf on each product team to being a centralised profession with consistent tooling and a shared approach to supporting all our software. So obviously I learned about Spotify’s engineering model (which subsequently became known as ‘the Spotify model’) and tried to lift it and drop it straight onto our world. Tribes, squads, chapters, guilds. The whole lot. And it didn’t work for us. At all. Spotify described the features of their approach but the benefits, the intent was implicit. So, for a short amount of time, we chased tribes, squads, chapters, guilds and what they meant for us. But without a clear ‘so what’. And then we abandoned it.

It made me feel better when, years later, I found out that Spotify also abandoned ‘the Spotify model’.

Part 1: The Product Management Community

Learn the key principles of a community and then figure out how to make them work for you

Skip to 2016 and I’m starting to lead the MOJ’s product management community of practice. I’ve started leading the profession in a sketchy, unofficial way. I still have hands-on responsibilities for product teams. There’s 10-12 folks in product management roles. Majority are contractors. There’s no clear leadership for the profession. There’s a regular meetup for those that want to attend. It’s mainly a place to talk, largely to blow-off steam, until the time is up. The role was sketchily designed and used inconsistently. Anyone could hire a product manager and use them as they wanted. There was no career pathway for permanent product managers.

Professions as a whole are in a weak place with an outgoing senior leader seeing little value in them. And even less value in heads of profession. A new senior leader joins and sees more value in professions but remains to be convinced.

‘Building Successful Communities of Practice’ by Emily Webber was released at the beginning of this year. I was already aware of some of the concepts in the book but loads were new. The book was incredibly helpful in framing my thinking and led to lots of action and decisions. Here’s what I did and what I learned in when establishing a community of practice.

Meeting together is important. Meetups are a part of the community. At times an important part. But they’re only one part. Trust is crucial and is earned through time together. Trust builds safety And safety promotes constructive challenge and questioning.
. . . but less important that you think. The most common mistake is to conflate a community of practice with meetups. Everything that follows is as important as meeting together.
If knowledge can be made explicit, make it explicit. A huge part of a community of practice is documenting and sharing knowledge. You’re not limited to asking someone in person at a meetup. Working in the open means that anyone can find knowledge and use it at any time.
Invest in shared role descriptions. Key skills and expectations of product management can still be unclear in 2022. This was even more so in 2016. We spent several months working on this. Organisations can be reluctant to adopt new things created by their own staff so I joined a cross-government working group defining product management for the whole of Civil Service. I was able to take our thinking and feed it into the working group resulting in something that immediately worked for us at MOJ. As a bonus, it was endorsed by the Cabinet Office. It cam packaged as a cross-government digital, data and technology capability framework linked to unlocking improved pay for digital specialists. This made it much easier to get buy-in for the roles within my own organisation. The role description improved professional development. It paved the way for much more open and fair recruitment and promotion too. And it helped challenge misconceptions about the role and how it’s used.
Create a handbook. 1:1s are a critical feature of a community of practice. I was managing all the PMs and began to spot the same things coming up time and again. I was recommending the same blog posts, books and talks again and again. So I started connecting PMs with the same interests together. And documenting the things I was recommending in a shared space. During the year this bgain as a wiki with a few links to existing posts and books. However loads of the existing stuff was for commercial organisations. Particularly Californian tech startups. It required recontextualisation tweaks to be directly useful in UK public services. So a bunch of Google Docs recontextualising existing stuff developed. By the end of the year we had a single Google Doc called the ‘product management handbook’ that pulled together all the things we most commonly used or needed. Skip ahead a year and we moved it to a Google Site to make it easier to use. A few other Depts asked if they could use it so I put a version online for others to use. It’s still there, albeit a few versions behind the MOJ one.
Define membership. Something we had to be explicit about was membership. Who’s in the profession? How do we gain entry to the profession? This can be difficult. It can challenge colleagues. Senior colleagues had been able to badge people as ‘product manager’ until this point. Some colleagues had applied the badge to themselves. But it was critical for the integrity of the profession. We had to create and protect a reputation for excellence. And we had to ensure entry to the profession was open and fair (versus ‘tap on the shoulder’).
Have some goals. It was important to have shared goals to build some momentum behind the profession. The bullet-points above give a sense of those early goals. We all wanted a clear and consistent understanding of the role. And we wanted a chance for career progression. These early goals were basic but they built the foundations of the community.
It’s OK to begin with a single leader. I avoided leadership for too long. It is possible for a professional community to shared leadership over time. But I’ve never seen an immediate jump to this model work. A professional community needs a traditional, single leader at the beginning. I lacked the confidence and self-awareness to go with this for at least 6 months. It took a while for me to finally pitch myself as a clear leader. And no-one blinked. They trusted me. I’d been doing it anyway. It made things simpler.

As a result of all this, starting 2017, we were able to cement our role descriptions. The only route into the profession became via open and fair recruitment. Recruitment was led by the profession. It sounds obvious now but we agreed that product managers should be managed by product managers. Until then management could end up provided by anyone. We agreement to open our first permanent, Senior Product Manager campaign. Later that year we would see our first internal promotions.

Don’t get me wrong, things could still be messy, that’s the reality of change in a large organisation. But we had a much clearer sense of what we were doing, why we were doing it, and how to do it. And a better sense of belonging to a shared profession.

‘If I knew then what I know now’ I could’ve done things better (and have done since). I was able to hire Emily and we worked together at the beginning of 2017. By this time Emily had introduced indicators of community maturity. We used it in a new area of the profession. Each indicator of maturity was a card and the PMs did a card sort. They agreed what was ‘done’ and what was ‘in progress’. This gave a sense of the maturity of the profession. What was done and what was in progress. And gave a chance to prioritise what happens next. This was a great way to build-up a 3-6 month backlog of shared community activity. I’ve used this approach several times since. You can achieve in 1-2 community meetups what it took us a few months to figure out back in 2016. Hiring an expert like Emily was a great opportunity to ask questions, test ideas and gain support. It was also useful to build trust internally about the approach we were taking.

Psychological safety

I’ve not seen much written about the emotional cost of introducing psychological safety to a community of practice. ‘Psychological safety’ was a buzz-phrase in digital circles for a while, made popular by a post on ‘the five keys to a successful Google team’. My take is that we should all feel safe to turn up to work as our true selves without fear of negative consequences. And we should feel safe to be constructively honest and challenging in our interpersonal relationships within groups at work. Organisations that foster this kind of psychological safety typically foster high-performing teams. Google repopularised this around the time we were working on our professional community.

What comes after the successful introduction of psychological safety can be hard. If you introduce psychological safety within a group it can build personal trust in you from individuals within that group. That trust is precious and has to be respected. Every time I’ve setup a community and helped build trust there’s followed a few weeks, sometimes months, of finding out what’s going on in the real lives of people in that group. I’d regularly get messages on Friday afternoon, when folks have a bit of downtime at work, asking to talk about something. And I’d learn what people had been holding onto for months, sometimes years. It could be a work life thing. A real life thing. A combination of both. Often serious stuff. We’re all people and we’ve all got a lot going on that’s often invisible when we only see each other in sporadic, formal meetings. A professional community can leave more space for us to be our true, messy selves. If you’re leading the profession you can become a focal point for this. It’s a sign that things in the community are going well and people are starting to get the space and support they need. But you must be prepared for the responsibility of being in this position. And prepared for the emotional impact of those Friday afternoon chats. Tears at work are more common than you’d think. You’ve got to step-up and help the people in your community - but realise that you can’t do it alone. You are responsible for providing a safe space for something to be shared. But you can’t solve everyone’s problems on your own. You have to get help from your peers. It’s OK to connect someone with a colleague more suited to support them. It’s OK to ask for help in talking-through how to support someone. Make friends with your organisation’s policies, guidance and helplines. They may be buried in the Intranet but I bet they’re more helpful than you realise.

It’s important that your community makes safe space for its members. You might be the person who needs to create this safety. If you are, make sure you’re prepared for those Friday afternoon chats. Think about how to have these conversations. Think about how you step-up and support without trying to be a hero. And without burning yourself out. Make sure you have the same safe space for yourself.

Head of Profession and being ‘hands-on’

We developed a rule of thumb in our early years. Below five people in a profession and you need one person to do some occasional leadership activity. 5-10 people and you need one person to be 50% on ‘Head of profession stuff’. At some point between 10-20 people you need a full-time Head of Profession.

I learned this the hard way. In 2016 I was managing 10-15 folks. Forming and leading the profession. And ‘hands-on’ in one product team and one discovery. I nearly burned out. But I had senior colleagues who agreed that we needed at full-time Head of Product. and was able to apply for (and get) this role.

It’s tricky though. There’s a lot of anxiety around no longer being ‘hands-on’ and losing your specialist skills. I was at a conference a few years ago and someone asked me if I was mainly doing people management now I was Head of Product? I said ‘yes’. And that people management was the role of a product manager, right? Product Managers don’t do anything. We listen. Think. And speak. In that order. We listen to the perspectives in our team and find value in the sweet spot where they align. A team is a team is a team. A management team is still a team. As Head of Product I had become the product manager in a management team. I was still creating value propositions, outcome-driven goals and aligning multidisciplinary perspectives. I tweaked my approach a little and to fit a management team. I remained ‘hands-on’ as long as I continually learned and improved and made products more valuable. Leading your profession and designing it to work well at scale is very much delivery. It’s delivering the capability your organisation needs to do its work. By coaching in your specialist skill at large scale. By all means reflect on how you tweak your specialist skills to work at scale within a management team.. But don’t allow yourself to get lost in worry that you’re no longer ‘hands-on’.

So a year or two into the professional community and our organisation grows. A lot. Digital and Technology within one organisation merge. And then merge with Digital and Technology teams in four other organisations. We find ourselves in a new Digital and Technology super-function. We’ve gone from a world of about 100-150 people to a world of over 1,000 people within a year. The community is now spread across several business units and many locations. We have new members and have to restart some of our community building activity. Our profession doubles in size.

Until now I’ve managed everyone. I designed the role descriptions. Designed the job ads and recruitment approach. Chaired all interviews. Made all hires. Onboarded the new folks.

I need to share leadership activity with my peers.

We have our first permanent Senior Product Managers. I’m able to share share meetups, recruitment, 1:1s, coaching and mentoring with them. This feels weird at first. Let’s take recruitment. I’m pretty anxious about relaxing my control of this activity and handing it over to others . . . but it’s fine. It’s more than fine, it’s good - the Senior PMs bringing their perspective and improve it. Sharing leadership activity with me strengthens the profession. We lose a single point of failure/bottleneck (me). And gain diverse leadership of the profession. Each I share leadership of an activity I can introduce a little more strategic activity to my role. I have the headspace to solve the root cause of some of our issues instead of treating the symptoms. You can’t do that if you’re Chairing five simultaneous recruitment campaigns and line managing 15+ people.

Localisation and contextualisation becomes important. We make space for it alongside the original need for process and consistency.

It’s still important to all meet together as a profession. It’s only feasible a couple of time a year. But it’s worth the effort to reconnect with each other. Regular meetings now happen in segments. We develop 2-3 community meetups based on geographical location. I spend the day in each location on the day of the meetup.

Our shared artefacts keep us connected between big meetups. The handbook, role description, approaches to recruitment and learning become even more important. We introduce separate Slack channels for segments of the profession. But keep our main, shared channel. All are open and accessible by all. Weekly updates give me a chance to share what I learn with everyone. People joining, people leaving, interesting reading, product updates, etc.

I reposition myself so I represent everyone. I can’t embed in the ‘original’ community as this reduces trust in me from the other locations. I give up my permanent desk and become a peripatetic* Head of Product.

*I’m allowing myself this one, obscure word. I take ‘peripatetic’ to mean someone who travels from place to place, working in each place for short periods.

The accidental community of cross-government product leaders

Head of Product meetups began with the creation of the Digital, Data and Technology Profession Capability Framework. We working together on the product manager role description, skills and career pathway through regular all-day sessions over 6-months. This gave us the space to get to know each other and build trust. We build a cross-government community of product leaders by accident. We made knowledge explicit, defined the role, agreed membership and set goals. All the stuff we were doing locally, recreated at a system-level.

This was done in a way that crossed organisational boundaries. It contributed to a similar product management identity shared across many Departments. Heads of Product also supported each other to promote product within our organisation. I’ve supported, and received support from most of the other main Departments.

Writing in the open has helped me to make links. My MOJ blog posts and personal blog have led to conversations, collaboration, speaking events, and attracted new candidates. Sometimes they’ve simply helped people in their day job. Behind the scenes, they’ve led to two side-hustles. The first is supporting new Heads of Product in Government. The second is support for people who’d like to share their experiences through blog posts of their own.

Heads of Product worked together at scale. Looking at hundreds of product managers helped us to see patterns. Most prominent to me was the need to differentiate the needs of the community as it grows. A couple of us did a retro of the cross-government product manager network. Meetups on how to roadmap for a single product remained useful for those new to the profession. But senior product managers needed a space to figure out what it means work across a group of products. Heads of Product and some Leads needed space to figure out what it means when the backlog is a portfolio and each ticket a whole product. Contexts varied too. Someone working on a greenfield public-facing product probably has a different experience from someone building a staff-facing product that has to integrate with multiple existing systems. Big meetups for everyone no longer worked as the single tool for keeping communities together.

Product management cross-sector

This same theme played-out cross-sector too. I attended Mind the Product meetups soon after they became a thing. They are great. But at a certain point they were no longer suited to the scale I was working at. Mind the Product recognised this too and introduced Product Leaders meetups (free at the time, now subscription-based). Much like Heads of Product in Government had been meeting up together, this was a space for Heads of Product. Directors of Product and Chief Product Officers from all sectors to meetup. It was a safe space for us to take about product at scale. About growing the profession. Working across many locations. And increasing the influence of product within an organisation.

For those of us who attended from Government it was also great to reduce status anxiety. Public Sector often assumes that private sector has everything figure out. They don’t. They’re human the same as us all. Government was working at a scale and in tricky spaces far in excess of most private companies. We are sector-leading when it comes to being user-focused and mission-driven. In particular, Government’s approach to Discovery and Alpha is some of the best you’ll see. This helped us be honest about what we could offer candidates. We couldn’t compete with the base salary in many of the best-funded tech companies. And couldn’t offer the chance to work on products that’d appear in Wired. We could offer genuinely user-centred ways of working. And mission-driven products that really help people. We had lots to learn from other sectors and I remember the folks at Financial Times being particularly generous with their time for which I remain grateful.

I also picked-up sporadic coaching of commercial product leaders through these meetups. In return I got to keep my insights into this sector up to date and bring lessons back to my own profession.

The folks at Mind the Product have put a huge amount of effort into supporting the product management community over the years, across all sectors and all parts of the globe. It’s hugely appreciated and they more than deserve their recent acquisition.

Distributed leadership

. . . and back in the world of the MOJ’s product management community of practice. One day I realised that a local community, just one part of the profession, had 15 members. That was larger than the whole profession when it began a few years earlier. Remember that rule of thumb about when you need a full-time Head of Product? Well, at a certain scale, it kicks-in for Lead Product Managers too. So I worked with some of my peers to introduce the role of ‘Lead’ to the organisation.

It takes time to trust in new Leadership roles. There’s understandable anxiety that they’re not ‘hands-on’ in delivery. It represents change for management teams. Until now digital specialists existed in product teams. It’s a big shift for a Lead to appear in a local management team.

But we get one Lead Product Manager. Then another. And another. And so on. My role became leading at scale. We got from 30 PMs, to 40, to 50, to 60. The nature of my role changes and I switch to working with and through a team of Lead PMs. My take is that leaders lead by going first. So anything new: it’s my job to go in whilst it’s messy and figure out what it looks like before asking anyone else to work on it. I have to provide the core, consistent principles for the profession. But I have to recognise my limits. And the limits of any principles. They need to be flexible. The Leads need space to localise them and contextualise them so they work in reality.

Shared parental leave

I took most of 2020 as Shared Parental Leave. This was a great chance to stress-test the product management profession. Had we designed a built a profession without a single point of failure?

We ran a review and retro. The profession was mature enough to continue for without an active Head of Product for a time. There were gaps. It did weaken the profession in some areas. But the profession as a whole, and the local communities led by each Lead Product Manager, were strong enough to thrive. Circling back to Emily Webber’s community maturity model: the profession as a whole was ‘mature’, with examples of being ‘self-sustaining’. Individual communities within the profession were more or less mature at any one time. Energy-levels for community of practice ran in cycles. But as a whole - we’d built a strong profession with leadership distributed across several local communities of practice.

From ‘busy’ leader to strategic leader

I’ve learned that the first years building a community of practice is hands-on, reactive people-work. It’s doing all the recruitment. And having to write the role descriptions and interview scripts first. It’s doing all the 1:1s. It’s switching from mainly contractors to mainly permanent staff. It’s personally knitting links between members of the community. Chairing meetups. Documenting knowledge and re-sharing it at the right time. It’s building trust in that professional community with other professions and with colleagues. All so the role is used in a way that’s valuable to the organisation and rewarding to the people doing it.

A few years in it switches. To building-out the career pathway. Developing, promoting and recruiting other leaders to join you and the profession. Sharing leadership activity with senior peers. Then distributing leadership with local Leads. Each success creates a little more space to be reflective, proactive and strategic.

One day I found myself with an entire afternoon of unscheduled time where, in that moment, everything was being led by others. And I had time to think.

Part 2: Ecosystems

Professions as silos

Communities of practice bridge across organisational silos. That can be from one team to another or from one division of the organisation to another. I started to notice something as I began to have time for strategic, reflective thinking. I realised that professions were on the brink of becoming new silos. Professional communities in government had defined ourselves to ourselves and for ourselves. But we’d forgotten to define how we work together in teams to get things done.

I led Service Standard at MOJ from 2018, ensuring we were taking a Lean Startup-style approach to developing and running 40-50 products. And in early 2021 I leadership across the user-centred, product and delivery professions spanning 350+ folks. Hundreds of people across dozens of products were saying the same thing. It’s hard to figure out how our specialist roles work together in multi-disciplinary product teams. We need to figure out how teams work together as well as we’ve defined individual roles.

Communities are just one part of the story

That brings us to Spring of last year. I was newly returned from a year of mostly shared parental leave and 12-months into the global pandemic. I began leading MOJ’s Heads of Profession, working with some of the most senior and experienced specialists in government. We switched our thinking from how we work separately to how we work together.

We realised that communities are just one of the features needed for us to become innovative. For me, innovation is when we solve new problems. But many organisations solve the same problems again and again, in silo after silo, in generation after generation of the workforce. How do we break out of this and start solving problems once, sharing, and then moving onto the next problem?

We realised that we had to design our organisation as well as we design our products. Each of us has brought our own inspirations. I was inspired by ‘The rise of community curated knowledge networks’ by Sari Azout. Together we’ve worked on shared designs that link our professions. We hope they’ll help us build a better understanding of how we all work together in teams. Here are the four key features I believe will improve sharing across 6 professions. Made of over 350+ amazing people. Building 40-50 fantastic products:

Communities. They remain important. They’re places to find a sense of shared identity. To make implicit knowledge into something explicit and shareable. To re-find knowledge and re-share it. But communities of practice within professions are not enough. On their own they risk becoming just another silo. We need other communities that cut across professional boundaries. Like communities of interest. For example, somewhere that anyone working on a Discovery can come together, share and learn from each other. And communities of action. For example, somewhere for people to come together and improve knowledge management.
Knowledge. Communities are great space to solve problems, taking implicit knowledge and make it explicit, documenting it in a way that can be shared. But it takes a lot of work to store this knowledge in a way that can actually be found and accessed. There’s work to use common tools, to have common taxonomies, to keep the information up to date and useable. The most radical act of innovation that many large organisation could make is to invest in a Content Designer and Librarian.
Curation. “We consume information recreationally, not as a way to achieve our goals”, to quote Sari Azout. To quote Audree Fletcher, “shared documents are not shared understanding”. I spent years designing and updating the product management handbook for my profession. After just my first few months of shared parental leave it was already being forgotten. A few months later and some new starters to the profession had never heard of it. Knowledge needs to be curated and regularly put in front of us, discussed and explained, if we’re to actually use it. Communities, 1:1s, coaching and mentoring are all great places for knowledge to be curated and brought to life.
Standards. I think standards add a ‘so what’ to this whole thing. Standards can reward us for starting from what’s already been figured out. And provide consequences for choosing to unnecessarily reinvent the wheel. They can provide a way of framing knowledge and provide the motivation to curate it. When standards truly matter, an organisation can solve problems once, for all, then move on to solving new problems.

Joining together we realised how much goes on in each profession. And realised there’s so much going on that we’ve been cancelling each other out. Each profession tries to solve similar thing in its own way year after year. But without space to work together and share we end up treading water. So Heads of Profession decided to become a true team, working together to build a shared vision and to set shared goals.

Much of our approach is about finding the awesome stuff already happening and clearing the way for it to be finished. We’ve developed some principles for how we work together which I’d summarise as:

Solve problems once, for all
Prioritise a small number of problems to solve together. And deciding what we’re not going to work on.
Take the invisible work needed to create great products and make it visible
Find, support & amplify work in progress before starting anything new
Prioritise most valuable work in progress that can be pushed over the finish line.

I’m pretty excited about what 2022 holds for the user-centred, delivery and product professions at MOJ.

Epilogue

I won’t help to write the next chapter in the story of professions and communities of practice at MOJ. I leave in a few weeks, moving to the public sector to work in Local Government. The Heads of Profession are running as a self-organising team. The Product management profession will have a new Head of Product. This is one of the reasons I’m excited to see what 2022 has in store for the user-centred, delivery and product professions at MOJ. It’s totally unknown to me for the first time in years.

This post isn’t the story of the product management profession at MOJ. That’d need 150+ voices to tell it. This isn’t the story of the Heads of Profession team at MOJ. That’d needs six people to tell it. But this is my story. A story about what it’s like to lead the same community of practice for a long time. It’s the story of what happens as the people in that community change, as enthusiasm ebbs and flows, and as the community grows, spreads and matures.

I’ll try and boil this whole thing down. I learned some things the hard way. If you’re in a similar role, let me share just three things with you:

You can’t solve every problem. The colleagues I saw who tried doing this burned out and left. If you’re in for the long haul then you have to learn to prioritise and let things go.
But you must solve the important problems. Cynicism is waiting for those who switch-off. I bargained with myself that I could let some stuff go as long as I had one important problem I was solving at all times. And that I’d see each problem through to a solution.
Get yourself some support. I can leave a product failure at the door but people stuff keeps me up at night. You can’t succeed at everything. Not everyone will get on with you. You won’t get on with everyone. You’ll come under pressure to compromise your values. Sometimes you’ll have to hold the line without anyone to pat you on the back for doing so. If you keep ‘open and fair’ as your north star and ensure each year is better than the last: then you’re doing the job and doing it well. Find at least one person who you can talk about all this stuff with so you can leave it at work and enjoy your real life.

A Beginner's Guide to Porter and Stout

2021-10-12T00:00:00+00:00

Blame it on ribs

In the 2010s my partner and I would regularly go to Duke’s Brew and Que ribs restaurant in De Beauvoir Town (an area in Hackney, London). They were ahead of the curve in brewing and selling their American-inspired craft ale. I really enjoyed their American pale ale and realised I’d never truly liked lager if I was honest with myself. I’d just drunk it because that’s what you drink. After a few years and a few trips I finally tried their porter and something clicked. I really liked porter. Another few years later and porter and stout are pretty much the only beers I like.

So for anyone else who’s not a fan of lager but has found themselves enjoying ales, here’s some of the stuff I’ve learned about porter and stout over the years. I’m not presenting myself as an expert - more someone who’s a few bits of internet research ahead of your average porter and stout drinker. I should also say: the most fun way to learn about porter and stout is just to buy some and try them out. I was drinking it for years before I started to get the first clue about what I was drinking, and it didn’t harm my enjoyment a bit. But if you’re looking for where to start, or looking for what to choose next, read on and you’ll hopefully get a tip or two.

A brief history of porter

The very short version of the stuff you can pick up from a few Google searches and a few Youtube videos is as follows. English porter was a popular style in the 1700s. Stout grew out of porter as a stronger version. The first few were literally called ‘stout porters’, eventually the ‘porter’ was dropped and the ‘stout’ remained. Nowadays the difference between the two is blurry and it’s easiest to see them as an interchangeable, collective term. What you’re (mainly) getting from porter and stout is a roasty, dark ale (owing to its common use of brown malt).

A quick guide to types of porter and stout

I watched an incredibly informative video about beer on Youtube. Below I’ve cribbed and summarised their summary of types of stout in case it helps you to think of what type you might like to try first:

Irish stout e.g. Guinness - easy drinking
Extra stout - stronger
Foreign extra stout - stronger still
Tropical stout - like foreign extra stout in strength but probably tastes sweeter
American stout - a little more intense (burnt, espresso)
Imperial stout - strongest of the stouts. A lot of brewers in UK name their strongest stouts ‘imperial’ stout. This is where ‘imperial’ used to describe the strongest version of a style comes from
Sweet stout - moderate strength, often brewed with the addition of something. Like lactose, in which it’s called milk stout. Yeast cannot ferment lactose. Sugar remains through fermentation. Gives a sweeter, fuller bodied beer.
Oatmeal stout - Oats will tend to give it a smooth texture.

There are specific types of porter too, with Baltic porter being maybe the most visible. You can find claims at defining exactly what a Baltic porter is but, to be honest, there are always so many exceptions to any rule that it’s not worth worrying about. The thing that all Baltic porters share is that they’re brewed in countries around Baltic sea. There may be a different approach taken to fermentation than you’d find elsewhere. But in any event: there are some cracking porters brewed in the Baltic region and they’re worth trying.

Recommendations to get you going

All that being said, here are some porter and stout recommendations from those I’ve had and enjoyed in recent years.

Beavertown Smog Rocket is a smoked porter. It’s got me into craft porter and stout back in those visits to Duke’s Brew and Que. The brewery eventually outgrew the restaurant (which is now closed) and today is called Beavertown.

I’m a sucker for sweet porter and stout. Hamerton’s Crunch Peanut Butter Stout and Amundsen’s Dessert Series are some of my favourites. I’ve been getting into Northern Monk of late and recently enjoyed their PB&J Cornflake Stout. Lervig’s 3 Bean Stout is something I’ve had many times.

I enjoy coffee porters and stouts too. Magic Rock’s Common Grounds Coffee Porter and Hitachino’s Espresso Stout are frequent favourites.

Põhjala brews some cracking Baltic porter. I’m finding them harder to get hold of right now, with everything going on around the world, but you can still get them in some craft beer shops. Must Kuld is one of my favourites.

Closer to home, The Five Points Brewing Company in my home borough of Hackney has their Railway Porter that I’ve enjoyed many times.

This is by no means a comprehensive list, just the tip of the iceberg. It’s just a handful that I’ve had the most often over the years. Cheers!

What are your favourites? Any porter or stout that you come back to time and again?

5 Tips for Successful Internal Platforms

2021-09-20T00:00:00+00:00

Large organisations often have internal platforms. My first assignment at the Ministry of Justice in 2015 was an internal platform to help development teams run and change their software. I got to pair with colleagues at GDS who were developing ‘Government as a Platform’. There was a lot of mutual learning and sharing in those early days, and I got to assess the early versions of a couple of their products. In the five or six year since then I’ve become a Head of Product, working with, supporting, and learning from many other Product Managers puzzling over what it means to work on a platform. I’ve gotten insights from within my own organisation, across government and from commercial organisations too. The challenges and opportunities are staggeringly consistent.

I’m revisiting platforms in 2021. My role has broadened and I now provide leadership across our user-centred professions of business analysis, content, delivery management, design, product management, and user research. One of our core value propositions is ‘improve how we develop and run our products’. One way we can do this is to take custom activity that we keep duplicating and instead package it up as a scalable product. So we’re looking at opportunities like a user-research library, design patterns, content systems, improved service manual, etc. All internal knowledge platforms. I pulled together an early version of this document in the New Year as part of this work and have been tweaking it since.

Below I share some tips for platforms but I’ll start off with a bonus one: don’t get lost in the word ‘platform’. A platform is a product, just like any other product. Granted: it’s a product that helps to build other products. But focus on the ‘product’ bit more than the platform and the rest of my tips become obvious. A product is a product. We shouldn’t cut corners just because it’s an internal product built for our colleagues. If a product’s worth doing then it’s worth doing right. Otherwise it will fail. Your internal platform is a product. It’s a staff-facing or business-to-business product so you’re designing for professional users. Give it the love and attention it needs and set it up for success.

Here are 5 hard-won tips for building successful internal platforms.

1. Trust is the key to success

Trust is the value proposition for internal platforms.

We all have a tendency towards exceptionalism. We believe we’re doing something so unique it requires a totally bespoke approach. The truth is we’re often more similar than we are different. Platforms take a custom activity that used to be in someone’s control. And remove that control.

People need to trust a platform before they’ll hand over responsibility for critical elements of their organisation. We need to invest more time and effort in helping people to use our platform than we do in building the platform’s features. An attitude of ‘if we build it they will come’ doesn’t work.

Successful internal platforms must design for trust. Trust is built in the real world, where customers and users interact with the platform. They need to engage with things like: Communication and engagement: Products need to speak with their users. Being an internal product doesn’t change this. Your communication strategy is critically important. Do you have one? Do you have someone on the team who’s dedicated to this?

Product support: Same as above. Being an internal product doesn’t excuse you from needing to provide
‘Sales’: How do we know if customers will commit to our platform? Early-stage platforms often talk about having ‘buy-in’ for their product. How do we measure and test buy-in? Janice Fraser has a model for this, suggesting we measure observable behaviour. Do potential customers demonstrate understanding of the product? Do they demonstrate belief in the product? Do they advocate for the product? Are they making decisions in support of it?
Change management: Introducing a platform requires customers and users to change how they work. There are many models to help manage this change, one example being the ‘ADKAR’ model.
Maintaining brand visibility over time: Platforms need ongoing activity and communication in order to maintain success after the initial changes are introduced. Once again, there are many models for approaching this. One is ‘the five conditions for collective impact’.

Platforms often start-off being described as ‘technical’. And might be run by a team referred to as ‘technical’, i.e. made up of one main skillset or specialism. This can overly focus on the technical features of a platform for months, even years. Broadening out the skills within a team can help increase the speed with which they realise they need to focus on building trust with their customers and users.

2. Aim for simplicity

We can simplify things when people trust us. It’s easy to fall into the trap of offering lots of options for customers and users to choose from but experience suggests that what they value most is simplicity. If they trust us, they want the benefit of things we’ve figured out on their behalf.

Thinking of the ‘Cloud Platform’ I helped develop in 2015: what we learned was that our software products at the time were similar. They were web forms with databases. Our Developers need our organisation to understand this and to design a platform accordingly. It was frustrating for them to be faced with lots of infrastructure options at the beginning of a product. We’d already figured out what our software needed, why didn’t we reinvent the wheel every time we started something new? They needed ‘sensible defaults’ that helped them to spin-up a new environment and get to work quickly. Without the need to make loads of decisions that we’ve already figured out before. The Cloud Platform introduced ‘sensible defaults’ that instantly provided the benefit of everything we’d learned up tol that point. Developers could change them as and when required but they catered to most situations.

We promote inertia when we keep solving the same problems again and again. Sensible defaults avoid repetitive decision-making in areas we already know. They allow us to invest our time and effort in solving new problems.

Simon Wardley’s mapping can help us to identify when it’s the right time to take something that’s currently bespoke and turn it into a product. And Wardley’s doctrine might help us to identify what simplification might mean in practice.

3. Understand your customers and users

GDS and MOJ were developing platforms in parallel in 2015. Platforms were seen as a ‘technical thing’ at this point and it was difficult to obtain researchers for platform teams. After establishing that platforms are simply a type of staff-facing product and aligning them with the Service Standard it became clear that research was a critical skill. However, existing modes of research didn’t work when lifted and shifted into this space.

Will Myddelton was leading user research for platforms for ‘Government as a Platform’ at GDS at this time. Will established version one of a model for research in GDS’ platforms and made time to share it with me. I took it back and we tweaked it for our context.

In summary, there are customers and users:

Customers: These are the people who will end-up paying to use the Platform. At MOJ, ‘Head of Digital’ was considered the main type of customer for the Cloud Platform. Research showed that their needs were fairly simple. They needed to know how much it would cost to host and run their software, something that had not been clear until this point. And they needed to trust that software would be run well and that incidents would be well-managed - along with help to communicate this to their internal clients.
Primary users: These are the people who’re using the platform. In the narrowest sense, this was ‘Developers’ for something like MOJ’s Cloud Platform. Although the whole development team might potentially use the platform in some situations and some contexts.
End users: For something like GDS’ Verify service, that appears within the user journey of software that integrates with it, it’s also necessary to research and test with the end users of that software.

4. Content is your competitive advantage

Let’s start with the obvious. Because it’s easy to ignore the obvious. The word ‘platform’ is often misunderstood and misused. It can get in the way of people understanding what the product actually is. It’s important to define the word and use it consistently. And to use it judiciously. Practically, it’s more valuable to define what ‘platform’ means to us - in our context - for our customers and users - than it is to define the single, all-encompassing definition of the word ‘platform’ for everyone in all places. Platforms are ‘staff-facing’ or ‘business-to-business/B2B’ products. Also remember, platforms don’t have to be technology. That’s where the definitions come from. But user research library, design patterns, etc, are all internal products that help us build products.

Beyond this, it’s content which is the main feature of the support wrapper around the platform in which we build trust with our customers and users. There’s a critical difference between technical documentation (e.g. comprehensive description of the thing) - guidance (e.g. simple instructions to use the thing) - and communication (e.g. helping people to find and understand the thing). Content is what helps people to use your platform.

5. Rewire the house whilst keeping the lights on

Platforms rarely come out of nowhere. They’re often the ‘productification’ of previously bespoke activity. This means they rarely have the luxury of starting from scratch. They need to meet existing commitments and support work in progress. Whilst simultaneously redesigning, improving, and productifying. This is like rewiring a house whilst keeping the lights on.

Platforms need at least two modes of activity to achieve this: One is ‘keeping the lights on’. Operational activity needed to meet commitments and support work in progress. Something like Scrum will probably work well here. Two is ‘rewiring the house’. Research and development needed to build and improve the platform. Something like Kanban will probably work well here. The team needs to separate these two modes and approach them separately. If they coexist in the same meetings and ceremonies then once will drown the other. Typically, operational activity will swamp research and development unless the team actively sets constraints around each type of work.

Yak-shaving is common. Unpicking situations where a platform’s approach goes against a local culture can uncover large and previously hidden issues. Estimation is difficult for this reason. Experience suggests that an estimate based on precedent - i.e. looking at the closest previous work and assuming it’ll take a similar amount of time - is more effective than general sizing activity.

There you go. Five tips for product managers looking to create successful internal products. I think being assigned an internal product was the making of my carrer. It felt so strange and alien that I had to return to first principles in many areas and ask ‘what’s the intent behind my normal product management tricks?’. Hving reconnencted with first principles it freed me up to be pragmantic: keeping what worked, dropping what didn’t work, and filling in the gaps through learning from experience and from others. Are you in this space now? How are you finding it? Do any of the tips sound useful for you? Have you already noticed something similar and tried it out? Have you developed any of your own tips for internal products?

What type of product manager are you?

2021-08-16T00:00:00+00:00

Folks ask me how to get into product management. I could talk to fill time and make myself feel important. But instead I stop and ask them what kind of product management they want to get into?

We talk about ‘product management’ like it’s a single thing. But it isn’t. There’s no meaningful or useful certification. There’s no real professional body. There’s folks doing stuff. Product management means different things to different people. The day-to-day reality of the role can vary from organisation to organisation. From product to product. And, sometimes, from hour to hour.

I’ve created a diagram to show the main types of product manager. It’s based on personal experience and the experiences of others. There’s no ultimate ‘right’ version of product management. There’s right for right now. If we’re choosing the right version for the right reasons then everything’s good. What’s important is to recognise the types and use them with intent. I’ve been all these types of product manager over the years.

Let’s look at our diagram and ask the question: What type of product manager are you?

The diagram’s got two axes.

Axis 1: Product Owner → Product Manager

Product Owner is someone who leads their team’s tactics for building something.This version of the role might focus on outputs (e.g. software features). At its simplest, we’re playing the Product Owner role as described in the Scrum Guide.

Product Manager is someone who leads their product’s strategy for improving value. This version of the role focuses on outcomes (e.g. benefits for their users and their organisation). At its simplest, we’re playing the Product Manager role described in the UK Government’s Digital, Data, and Technology Capability Framework.

Spectrum 2: Jack of All Trades → Specialist

Jack of all Trades is someone who provides many perspectives within their team. This version of the role may do some research, some design, and some of the technical tasks. They may be responsible for sales, marketing, or support. At its simplest, we’re doing most of the work with occasional support.

A specialist is someone in a multidisciplinary team. This version of the role is not covering gaps in the team. They have time to be product management-y. At its simplest, we’re understanding the specialist perspectives of others and looking for value in the sweet spot where they align.

Where might I be a product owner?

I see product owner commonly used in technology startups. I’ve been a product owner in this space. I see lots of product owners in this space through interviews and conversations. Common characteristics include:

Founders remain ‘hands-on’ in leading direction for the organisation. The own the business model and the product strategy
Technology is the focus, as is increasing users. Engineering (and Design sometimes) are the dominant professions in the organisation Product is being introduced. The first product managers may be engineers and designers moving into new ‘management’ roles. Their focus is helping teams build new technology features.

I’m using technology startup in a broad sense. This covers the spectrum from commercial companies making apps to large non-profit organisations introducing ‘Digital’ teams for the first time.

‘Product owner’ can be a good version of the role in this context. There’s high confidence in the problems. Product strategy is owned elsewhere. There are clear goals. ‘Delivery is the strategy’.

Issues can arise when this approach is taken but assumptions about the problem, the strategy, and the goals are untested. The organisation is set on a trajectory that’s moving away from reality. It’s hard to course correct when product is used in this way. Further issues can arise if founders or leadership remain too hands-on when the organisation becomes too large for them to do so effectively (‘founder’s syndrome’).

Where might I be a Product Manager?

I worked for myself for a while. Some clients wanted me to act as a consultant and review their business model. In these situations my time was not spent leading a development team. I was paid to help them find product/market fit and improve profitability.

Let’s take one of my clients. They hired me when they were coming to the end of their funding and had to become profitable. I focused on their customers and found that their sales time was 3-9 months. This was because their information security generated lots of questions. I made the case to prioritise information assurance accreditation for three months. This allowed us to reduce sales time to 1-3 months. It also gave us time to explore procurement processes for our customers. We realised we could quadruple the cost of the newly secure product without affecting sales.

This is the kind of situation where product management can be a good fit. There’s low confidence in the problem. Low confidence in the solution. And a broad scope to make changes, quickly, based on testing in the real world.

Issues can arise if this approach is taken when there’s no real scope to change. If we’re running a website development project. And it’s the fiftieth one we’ve done. And it’s entirely typical. Then this type of product manager could easily become overkill and lead to a waste of time and money. Further issues can arise if this type of product manager is hired but only has the scope to function as a product owner. Or is expected to be a jack of all trades.

Where might I be a jack of all trades?

Some organisations have one or two specialisms that dominate their culture. I did some digging into associate product management schemes a couple of years ago. It was interesting to read one of the tech giant’s programmes. They said that their focus was engineering. They wanted product managers to fill the gaps in the team. To support engineers to do engineering by taking care of the other stuff.

This can work well when the organisation is clear on its problems and solutions and needs help to focus on delivering outputs. Issues can arise when this isn’t the case as it can enable an organisation to continue in a direction that’s no longer working.

In other organisations it’s a simpler reason. Money. Organisation only has the money for one full time role? A Product Manager may seem like they can do the lot. Does this sound farfetched? I’ve been a product manager in a non-profit where there were only eight people in the whole organisation and I had no permanent support. Beyond some money for help from a digital agency, and some volunteers, it was all me. I’ve met or interviewed lots of people who’ve had a similar experience.

This can often work well from the perspective of the organisation. They’re getting a lot from one person. The issues can be for that one person. Long hours, burnout and problems with health and relationships can be the end result.

Where might I be a specialist?

Some organisations have multidisciplinary teams comprised of the skills needed for their products. They need product managers to play a smaller, more ‘specialist’ version of the role. Their specialism is to understanding the different perspectives of their team. And find value in the sweetspot where they align.

From a personal perspective, working in Government is where I’ve most needed to play this role. And where I’ve most been able to play this specialist role. Digital products created in-house within Government need to have multidisciplinary teams. It’s a condition of their investment.

Issues can arise if we hire this type of product manager but have gaps in the team. When faced with real people who need help versus a more abstract ‘product strategy’? People (normally win). This can leave a gap where the product strategy should be. And can leave the product without real direction.

What type of Product Manager are you?

Do you recognise the range of product management shown in my diagram? Do you recognise that you’re in one particular quadrant? Do you think that’s where you need to be? Or is it where your organisation has left space for you to be? Are you doing the right thing but have the wrong role title? Or are you doing the wrong thing with the right role title? Do you move around the quadrant a lot, playing different roles as needed? Are you in one quadrant and ready to move to another? Or are you very happy where you are?

Why I'm not frustrated with GDS' formal discovery/alpha/beta phases

2021-08-09T00:00:00+00:00

Earlier in the Summer someone shared their frustration with GDS’ ‘formal discovery, alpha, beta’ phases. See the original post here (Twitter). It got a lot of responses. There were two themes that stood out to me:

“Beware process ossifying into dogma”
‘Aren’t we doing discovery and delivery in parallel the whole time?’.

These were both things I’ve thought about for a few years because I lead Service Standard for my organisation as part of my role as Head of Product. Here I share some of my thinking along with how it’s influenced my approach.

“Beware process ossifying into dogma”

This is what Tom Loosemore said in the responses to the original post. It’s what I’ve held in mind since I became Head of Service Standard in 2018. For a process to be useful, we need to:

Understand the intent behind it
Understand our own goals in using it
Critically engage with it
Localise and contextualise
Be pragmatic.

I make space for this in my organisation. GDS’ ‘formal discovery, alpha, beta phases’ are the UK Government’s way of talking about the product lifecycle. I’ve found the product lifecycle to hold true for all products I’ve worked on, across all sectors. The product lifecycle has been a conceptual tool for improving product strategy for a long time. Here’s a republished article from 1965 talking about it. It’s been refined since, with people like Steve Blank going much deeper on the ‘customer development’ stage in his book ‘The Four Steps to Epiphany’. This was a core text when I tutored on the General Assembly product management course many years ago. Steve’s Blank’s thinking was an explicit influence on ‘The Lean Startup’. ‘The Lean Startup’ was published in 2011 around the same time that GDS was being spun-up. Joining the dots, it clearly influenced the shape of GDS’ thinking (directly or indirectly).

The standard product lifecycle is aimed at commercial products that measure success through sales. It requires contextualisation to work in the Civil Service where we measure success through how much we help people. ‘Amount of use’ is maybe a decent alternative for sales, where ‘use’ is defined as the number of successfully completed user journeys. In any case, it’s totally legit to tweak it. But ultimately: we’re just talking about the product lifecycle.

The product lifecycle is a core part of the product management role. We can’t do our role without it. Product strategy is fundamentally different from one stage of the product lifecycle to another. Our users and their expectations are different from one stage to another. While the boundaries are more blurred than diagrams would suggest, the stages are real. It’s so fundamental to our role that it’s one of the core skills listed in our role description on the Digital, Data, and Technology Capability Framework. You can blame me for that. I advocated for its inclusion back in 2016 when we were writing the role description. I’d noticed through interviewing, managing, and speaking with PMs that it was recognised to be important but was the most common skill that needed development. The other Heads of Product agreed and it was included.

Heading up Service Standard, I’ve held onto this. Most of our products are relatively small and so internally assessed. This means we can make additions to the standard guidance and assessments in order to (i) make their intent more clear so that (ii) we can localise and contextualise. We’re always true to the intent of the Service Standard. We never lower the bar. We never replace any existing guidance, it always remains our starting point. We add to it in order to make it work better for our context and to reflect what we’ve learned over the years. We work closely with GDS (now CDDO) and they’re totally supportive. We’re not doing our own thing. We’re just adding to the already amazing starting point that’s been provided. We were audited earlier in the year and received the highest level of assurance with no recommendations for change or improvement. It just feels like the healthy, positive thing to do.

So if you’re frustrated with GDS’ ‘formal discovery, alpha, beta’ phases I invite you to:

Revisit the intent behind it
Think about your own goals in using it
Critically engage with it
Localise and contextualise
Be pragmatic.

This could take the form of your Portfolio/Controls/Standards team pairing with your Product Management profession to lead a project to do the above with and on behalf of your organisation. And to partner and check-in with the Standards Team at GDS (now CDDO). I have never found them to be anything other than positive and supportive of our work. And the Service Standard and Manual remain the most effective mechanism for protecting a user-centred, product approach that I’ve experienced in any sector. They were a huge reason for me joining the Civil Service and have proved invaluable throughout my career here.

‘Aren’t we doing discovery and delivery in parallel the whole time?’

I think this is a red-herring. The same word can mean different things to different people. I think this has happpened with discovery.

There’s discovery, in a general sense. We discover things. We learn stuff that improves our products. This should happen throughout a product’s life. We should always learn and improve.
There’s Product Discovery, in a specific sense, within the context of the product lifecycle. A stage in which we invest a small amount of money in order to define a problem in order to gain greater confidence in figuring if and why we should build a product. We should invest the minimum amount needed to figure this out. And avoid sinking money into our imagined product until we’ve figured this out. The early stage of an opportunity is the riskiest. Not least because it’s where we know the least. But also because people talk about problems through solutions. The solution we’re all talking about right now is a metaphor for the problem. It’s easier to talk about an imagined solution than the problem we’re trying to solve because we haven’t had time to define the problem yet. Creating a list of things we don’t know about a problem is less motivating than a workshop thinking about a solution.

The product lifecycle is talking about Product Discovery in a specific sense. It’s requiring that we define our problem before committing to a solution. It’s saying that it’s not enough just to find a problem. We need a problem that’s valuable, urgent, and pervasive. If people are solving it themselves then we may already have an invisible solution. Or if someone else is working on solving it (possibly within our own organisation) then we may have a competitor. We need to know all these things before we invest further in an opportunity.

Let’s think even bigger.

We often think about the product lifecycle from the perspective of an individual product team working on an individual product. Let’s change perspective.

Let’s say we’re a large organisation. We’re looking at 50-60 digital products in varying stages of development. We know they’re all valuable. We’d love to pursue them all, and more. But we don’t have infinite people. We don’t have infinite time. We don’t have infinite money. We have to make hard decisions about where to invest tax payers’ money. From this perspective, the product lifecycle provides a series of investment decisions. Each time we’re asking: is this single opportunity worth pursuing in the context of all our other opportunities, given that constraints mean we can’t pursue them all at once? And if it is worth pursuing, can we help it connect with other opportunities where there are chances to learn and share from each other?

In UK Government, it’s a critical part of a Product Manager’s role to lead the team to these decisions. It’s the reality of the ‘product lifecycle’ essential skill. There will be Senior Product Managers and Lead Product Managers (depending on the size and maturity of an organisation) whose role it is to support with assessment of opportunities in the broader context that an individual product sits in. We should support, empower and require product teams to engage with these investment decisions at critical points of the product lifecycle. In an ideal world, assessments are just a place for teams to share these decisions and check their thinking with supportive peers.

Do you know an unsung hero of a product manager?

2021-04-03T00:00:00+00:00

I’m looking for unsung heroes working in product management in the UK government. The pandemic has shown how critical ‘digital’ teams in Government are. And how little praise and attention they get.

So I’ve set up a newsletter to find, support, and amplify good product managers in the UK government. Those who quietly get on with creating critical services for their country, improving lives as they go.

Do you know someone who deserves to have their work recognised?

Get in touch with me to share your recommendation.

You can email me. DM me on Twitter if we follow each other. Or message me on LinkedIn.

Let me know:

Name, organisation, and role of the person you’re recommending
What you want to recommend them for
What you find particularly interesting about their approach to product management
Details of how I can get in touch with them.

I’ll get in touch with them. If everything goes well I’ll:

Interview them for 45-60 minutes
Draft an article about their work
Share with them for approval
Publish via newsletter to a network of 300 people (and growing).

You can read previous examples here:

‘How to Align Your Product Team’, featuring Tobi Ogunsina (Senior Product Manager at the Government Digital Service)
‘Top Tips for Product Manager Meetups’, featuring Simon Manby (Senior Product Manager at the Ministry of Justice).

Let’s sing the praises of the unsung heroes working in product management in the UK Government. Share your recommendations and let’s find, support, and amplify these great folks.

2020 Highlights

2020-12-27T00:00:00+00:00

Parenthood

Me and my partner became parents. Our little one is the best. We shared parental leave throughout the year. Three months together. Four months with my partner leading care and me at work. Four months with me leading care and my partner at work. Then the final month together again. It’s a privilege to have the support of my employer to spend most of our baby’s first year together.

I can’t condense a year of new parenthood into something pithy and blog friendly. Instead I’ll pull out something that has stuck with me. Me and my partner split nights in the first few months. We swapped at 3am when I’d wake up and takeover care until 7am (I’d get more sleep later in the day). I’d head down to the lounge, hold my baby, and watch muted & subtitled films in the dark. It sounds rubbish but was oddly cosy. I got to see the days get a little longer each day over those dark months. Spring arrived eventually and we’d see the Sun rise each day. I don’t think I’ve ever experienced that before. There have been lots of things like this - weird, hard, exhausting, rewarding, idyllic - that I couldn’t have imagined beforehand.

The global plague meant that we couldn’t see much of our friends and family this year. They were sad not to see our little one as they’ve grown and changed. And it’s meant that we’ve had no time off, our baby has spent the entire year with one or both of us at all times. But the pandemic has had less of an impact than we’d expected, on balance. The whole year has been like the first mornings - weird, hard, exhausting, rewarding, and idyllic.

Few shout outs:

Me and my partner figured out that stress and sleep deprivation made us weird at times. We decided to trust each other and give each other a free pass, for the most part. If we were being weird or grumpy it was the natural consequence of having 3.5 hours sleep and being worried about keeping a tiny human alive
Our National Childbirth Trust (NCT) group was a life saver. Not being able to see much of family or friends could have made for a very lonely year. Knowing other parents in the area via NCT meant meetups for coffee and a walk at least 2-3 times a week. Weekly stay and play at the Children’s Centre also helped to get out and about with other parents
Victoria Park in Hackney has been great for getting out of the house, meeting people, getting coffee, feeding the ducks (and geese, and seagulls, and moorhens), and (more recently) swings and slides. Lockdown would have been very different without this amazing public space.

Coffee

I normally make espresso at home with my Gaggia Classic. It’s not particularly baby friendly. It takes a while to setup, gets very hot, and requires a lot of attention. Not something that works well alongside a small person. I switched to a moka pot for a while, and enjoyed it. But still preferred espresso. So I was intrigued when a new product appeared in the Summer. I watched a review of something that’s essentially a moka pot with an additional section that builds up the 9 bars of pressure required to produce espresso. The product’s called ‘9barista’. I bought one. It’s fun and fits my (extremely niche) set of needs. Here’s a Twitter thread showing my first few uses, and here’s a blog post with more info.

Coffee was an excuse to get out of the house and see people too. Me and my partner would go for walks for a takeaway coffee to escape the house for a bit. We’d meet other parents for a takeaway coffee then walk around the park. Takeaway coffee and cake was an easy way to support local, independent business. The coffee shop owners were lovely too. Our local coffee shop is particularly sweet with our little one and baked them a cake for Christmas. It was nice to have this little bit of normality in a year like 2020.

Running

I finally registered with a GP in September 2019 after a gap of a few years. All was OK except my blood pressure was a little high. Nothing to cause a problem now but the kind of thing that could be serious in ten years. Looking at reasons for this, it was probably due to salt intake in my case, so I cut this down. More exercise would help too. Small baby meant that walking naturally increased to 2-3 hours a day. Carrying babies and prams for hours a day covers off ‘doing weights’. The thing still missing was exercise to get me out of breath a couple of times a week. I swam competitively at school but had never made it fit into my life as an adult, despite trying for years and years. I’d also cycled and run as a child, to help my swimming training. I’d always enjoyed the cycling and disliked the running. So it was cycling that I’d tried to get back into as an adult but never kept at because I don’t find London a nice place to ride. I’d been stuck in these failed attempts to swim and cycle for about a decade. One day in July I was thinking about this when I was interrupted by a runner appearing in front of me. Then another. And another. And finally realised that running is probably the thing that fits easiest into my adult life right now. It sounds obvious, and it is, but it never ‘clicked’ for me before.

I decided to give running a go the same day that inspiration struck. I’m approaching 40 and know that my body’s a lot creakier than it was as a teenager. So i got some tips on how to run safely in your 40s. Then went out in my dog-eared shorts, battered Vans, and baby-sick-covered t-shirt. I started in the Summer and am still going at the end of the year. Here’s how it’s developed.

Location: Victoria Park is near me and lovely so I’ve always run here
Version 1: Decided not to track distance or speed. Or to buy any specialist kit. Just go out, run, see what happens. I ran until I felt tired. Then walked until I felt better. And repeated. I naturally covered the east-side of Victoria Park in this way. I was worried that I wouldn’t be able to do any distance at all so it was a good confidence-boost to be able to run after all these years. It took me about 50 minutes door-to-door, including walking to the park and back, and having two walking-breaks during the run.
Version 1.1: I did this a couple of times before realising that my old Vans were not appropriate footwear if I didn’t want to injure myself. My demands were limited (basically: a lot of cushioning to protect my shins and knees, cuz I’m old) so had a lot of options. I went with a pair from Nike because they were on offer, had a video explaining how they work featuring their product manager, and would arrive in time for my next run. They successfully helped me to run in greater safety and comfort.
Version 1.2: I’m running the east half of Victoria Park in 3 sections. I run the eastern-most side; then walk the corner; then run the straight along the canal; then walk across to the other side of the park; then run the back straight home again. I started using each section for a different purpose. First run is uphill so I took it slow, warmed-up, and paid attention to how my body was doing. Second section is flat so I’d run more quickly and get out of breath. Final section, I’d do whatever felt good on the day (slower if I was tired, quicker if I had more energy).
Version 2: My partner went back to work and I switched to solo-parenting during the week. This made running during the day trickier. I didn’t want to lose the momentum I’d built up so decided to buy a running buggy. They are expensive but I wasn’t spending money on much else so decided to take the plunge. I paused running for a couple of weeks to choose one, order, and build one, then got going again. I went for the Out n About Nipper Sport, based on some kind advice from others. Then carried on my running pattern as before except this time with pushing a baby in front of me. Running became hard. I was way more out of breath by the end of it. And showering when I got home became logistically more interesting.
Version 3: My partner’s work patterns change and twice a week they could go into work a little later. I made these my running days so I could run solo again and ditch the running buggy. The first day I did this I ran straight through my normal ‘walking’ section without noticing’ only realising later in the run. The buggy had helped increase my stamina in just a couple of months. I carried on doing the run with just a single walking section from this point.
Version 3.1: One day I decided to try running the whole thing without any walking. And succeeded! I was very tired. And had to slow down a lot for a couple of bits. But did it. I’d started running in July when the thought of being able to run the whole route in one go seemed silly. Skip forward to October and it felt ace to have made progress in a few months.
Version 3.2: A mate who runs properly joined me in November and we did the route together so we could catch up for the first time in months. He tracks his runs so this was the first time that I got some stats. I’m doing a distance of 3.25km, taking about 18.25 minutes, with a pace of about 5:43 minutes per km. I’d guess that I’ve run 120km+ over the year.

I don’t always enjoy the whole act of running, to be honest. But each run has moments I enjoy. Being the first person in the park in the morning feels special. Running through the mist is nice. And I always feel good afterwards. Next: In 2021 I’m going to try and build up to running 5km - helpfully, that’s the approximate length of the whole park. I’ll be happy if I’m doing that 2-3 times a week by the end of the year.

2010-2020 career retrospective

I took shared parental leave for a lot of 2020 and switched my brain off work mode, for the most part. But I also kept things ticking over in the background, helped by doing a ten year retrospective of my career. I gave myself 6 months. Didn’t rush. And learned things I’d never thought of before. You can see it here.

I’ve started a newsletter alongside the 10 year retro. It’s aimed at product managers in Government Departments or Agencies, Local Authorities, Charities, Non-profits, Social enterprises, or Non-Governmental Organisations. I’m hoping it’ll amplify product management that puts people before profit. Currently at 200+ subscribers after the first few episodes.

Book

The retro and newsletter have helped me to sketch out the bones of a book about product management that puts people before profit. The working title is ‘Good Product Management’. I’ve drafted 15,000+ words, have figured out the overall structure, and hope to finish and publish in 2021. You can see the most recent update here.

Ten Year Retrospective: 2010-2020

2020-12-24T00:00:00+00:00

‘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.

Book Update: The Beginning of the End

2020-12-14T00:00:00+00:00

Working title

Good Product Management Volume 1

Drafting

In my last update I spoke about creating a newsletter. My intention was to use it to chunk-up the drafting process. This worked well. I’ve published 15,000+ words of draft ideas and content. It’s gone beyond writing down what I know already and helped me to learn new things. The act of writing down my stories for an audience forced me to think in a sustained way. Often the newsletter episode was the beginning of thinking that I then took further and came to new conclusions.

One example was capability. I realised I’d never given serious thought to what I meant by skills and behaviours. How are they different to each other? This sparked some research and tweaking and led to a model for thinking about how our overall capability is linked to our specialist skills and general behaviours, helped by knowledge from others and improved through practice, practice, practice. This will help me tie together a bunch of stuff that’s felt loose and unclear until now, so it should be more valuable for others. This is just one example amongst many. The published episodes are often the tip of the iceberg of the thinking they helped me with.

The newsletter also helped me to think about the scope, structure, and format of the book.

Scope

I’ve reduced the scope of my book to keep my motivation high and check that it’s of interest to people. I’ve got the bones of a book on ‘hands-on’ product management already, thanks to the newsletter. I had planned to include product leadership in the book too but now decided to leave this out. It’s already taken me a year and a bunch of effort to get this far, I don’t know if my motivation will last another year before having something tangible to show for it. It’s also a good nudge to get something out there and see what the reaction is. I’m thinking of self-publishing a limited run (100-200 copies?) of Good Product Management Volume 1, focussing on ‘hands on’ product management.

Current thinking is that I’ll work on Volume 2: Product Leadership in 2021/2022. There’s good reason not to rush. Firstly, I’m a new parent and return to work in 2021. I’ve got other priorities and time will be tight. Added to this, my product leadership journey continues and it looks like I’ll have some cool opportunities coming up in 2021. I reckon they’ll stretch me and see me develop. So I should have more to share in the future.

Structure

Structure for Good Product Management Volume 1 likely to be:

Introduction including note on format of book (based on original signup message)
Chapter 1: Product principles (based on episode 1 of newsletter)
Chapter 2: Description of good product management where people are put before profit (based on episode 3 of newsletter)
Chapter 3: Product strategy and tactics (based on episode 6 of newsletter)
Chapter 4: Product management capability (including skills based on episode 4 of newsletter and behaviours based on episode 5)
Chapter 5: Getting into product management (to do)
Conclusion: To do

Format

Format for each chapter:

Main guidance to takeaway and use (for people skimming or revisiting)
Context explaining how guidance emerged, as how it is figured out is sometimes more useful than what was figured out
Real example of how this played out for me during my career (I tested this type of storytelling in episode 2).

I tested differing orders for newsletters, this seems to work best based on amount of opens and unsubscribes.

Next

I’m taking a break for the rest of 2020.

In 2021 I’ll work on finishing and publishing Good Product Management Volume 1. I still have some untested assumptions about this. I’m going to start testing them by speaking with friends and colleagues who’ve published books and work out from there. I had a dry-run with an author friend in November to refine my questions and tested feasibility of doing the interview via asynchronous Twitter DMs.

If things go well I might start work on a volume 2 about product leadership end of 2021/2022.

How to make espresso with 9barista

2020-09-27T00:00:00+00:00

This is a quick post on my new coffee kit, the 9barista, after several people asked about it. If you just want quick tips on how to use it then see immediately below. If you want more info on what it is, how it works, and whether it’s for you then see the end of the post.

Method

Temperature: I have a gas hob. I use the second smallest hob on full temperature. I initially tried on the smallest/coldest hob but the 9barista didn’t get up to pressure in time.

Baseplate: I have to use the supplied baseplate because I have a gas hob. I’ve found that preheating the baseplate whilst preparing the 9barista reduces the extraction time to 3 minutes and creates my favourite results.

Water: I use filtered water because I live in a hard water area (London). I filter my water using a charcoal stick.

Coffee grounds: I grind the beans finely, as you’d normally do to espresso. However, I use the coarser-end of espresso grind. I am currently using Square Mile’s Red Brick seasonal espresso beans, own a Sage Smart Grinder Pro and use setting ‘17’. My grinder costs around £200 in the UK at time of writing. I think that Sage is called ‘Breville’ in countries outside the UK.

Other than this, I follow the instructions that come with the 9barista:

you can see a summary of my first few attempts in this thread on Twitter
you can also see James Hoffman’s guide and review on Youtube. Using the above method, the espresso starts coming through after about 2 ½ minutes and finishes after about 3 minutes. Espresso should take between 3 and 5-6 minutes to come through, and should never be on the heat for more than 8 minutes.

I’m getting good espresso with 3 minutes of heating and 1-2 minutes of preparation. Pretty impressive.

Frequently asked questions

What is a 9barista?

I’d describe a 9barista as a moka pot (or stove top pot) with a cleverly engineered, additional section that builds up enough pressure to create genuine espresso.

What is genuine espresso?

Genuine espresso needs 9 bars of pressure. This normally requires a traditional espresso machine. Other brewing methods like moka pot and aeropress that claim to create espresso don’t really produce espresso because they don’t generate enough pressure.

Why have I bought a 9barista?

I love espresso, it’s my favourite type of coffee. In the past I have made it using my Gaggia Classic espresso machine but in 2020 I became a dad and no longer have the time or space to use the Gaggia. It takes a while to warm up, and most of our kitchen top is now taken up with baby stuff. I’ve been using a moka pot for several months because it produces something a bit like espresso but in much less time and requiring much less space. However, I missed genuine espresso. Nothing beats the intensity of the flavour for me. So I was pleased to see my niche set of needs being met by the 9barista, a machine that is (kind of) a moka pot with an additional section that creates sufficient pressure to produce espresso.

How does espresso from 9barista compare with a traditional espresso machine?

I own a Gaggia Classic with some modifications and it is capable of creating espresso better than the 9barista. But not every time. The 9barista is capable of creating good espresso every time, based on a week’s use creating 1-2 shots per day. My Gaggia Classic has more things that I can vary when making espresso so allows me more scope to experiment and tweak. The flipside is that it allows more scope to go wrong. The 9barista only has one moving part and the only thing you can really vary is the grind size of the coffee beans. It has a lot less scope to tweak and improve. But the flipside is that it’s relatively easy and consistent. Based on 1 week of 1-2 espresso per day, I’ve got better shots overall than I did with my Gaggia Classic, to be honest. 9barista produces significantly better espresso then I’ve ever had from a capsule espresso machine.

I think a 9barista is worth considering if you

Mainly make espresso for yourself: making espresso for yourself using a traditional espresso machine requires letting the machine heat up first, then maybe 1-2 shots to get it working well. It takes effort. 9barista doesn’t require this effort. Flipside is that it is not suitable for making espresso for several people (in my opinion), it’s not what the 9barista is designed for and would be impractical.
Aren’t too fussed about steaming milk: I mainly drink espresso without milk at the moment. When I do have steamed milk, I’m happy to heat the milk in a saucepan and use a French Press to froth it. But if you regularly have your espresso with steamed milk then I don’t think 9barista is practical unless you have a separate way of steaming milk.
Want espresso, don’t want to learn how to use a traditional espresso machine, but don’t want a capsule machine: Making your own espresso at home using a traditional machine is a hobby and requires skills and practice. Most people can’t be bothered by this. Capsule machines allow espresso at home very easily but the results are not as good as from freshly ground beans. 9barista is a sweetspot between then two. You get consistent results better than a capsule machine but with less effort than a traditional espresso machine.
Can afford £300 for the 9barista, around £200 for a decent grinder, and aren’t in a hurry: 9barista costs around £300 at time of writing. That is a lot of money for coffeee kit. It’s less than most traditional espresso machines (decent ones start at around £500) and is a fair price for what you get. But is still a lot of money. The company behind the 9barista is still small and all units are hand made to order (at time of writing) so it may take a couple of months to receive your order. You’re also likely to need a decent grinder if you don’t already have one, which is likely to be another £200.

Book Update: The End of the Beginning

2020-08-23T00:00:00+00:00

Enough people have asked me ‘how’s the book going’ that I figured I’d write an update. The short version is: I’ve finished the beginning.

Working title: Good Product Management

The working title started as ‘product thinking’ but has switched to ‘good product management’. I’d always preferred ‘good product management’ but then I saw Lou Downe’s book ‘Good Services’ and figured it was too close. I’ve not found anything I liked better. ‘Product thinking’ felt like I was clutching at straws. And nothing’s original anyway :) So I’ve gone back to good product management. Got the domain name and everything. By the way, Good Services is on my reading list, it’s been recommended to me by several people.

Who’s the book aimed at?

I’m going to focus on products and services that improve lives because that’s what gets me out of bed in the morning. So I’m imagining it’ll be of most interest to folks working in government departments or agencies, local authorities, charities, non-profits, social enterprises, and non-governmental organisations.

What’s the book’s ‘hook’?

I’ve been trying to find an ‘in’ to the book and think I’ve got it. I was chatting with my partner recently, describing what I’d actually done in my career over the last few years. They said ‘ah, it sounds like people find change uncomfortable and you help them with it’. Which seemed like a good summary and gave me the ‘hook’ for my book. People find change hard. Groups of people find change particularly hard. My experience of product management is that I’ve created space to decide on the right change to make at the right time, to improve the value of products and services for users and the organisation. It normally starts with big changes, and then becomes smaller, more frequent changes.

What’s my approach?

A colleague recently asked me if I’d seen that John Cutler has recently paused work on his product management book. I can empathise with his reasons: lockdown is hard and needing to be there for his partner and baby. My situation sounds similar. What I’ve taken from this is: I’m not going to stress if the book doesn’t happen, or I need to pause it for a while, or if it takes a while. I’m doing it for fun. If it stops being fun then I’ll stop work on it. My guess is that it was a hard decision for John but once it was made it felt like a weight had been lifted.

I’m still enjoying writing at the moment but I have made a decision to keep my scope narrow. I’m definitely not trying to write THE definitive book on product management. Instead, I’m going to share my personal product management story. It’s not going to be an exhaustive list of every method of split-testing software (for example). But what it will be is an honest account of me trying to figure out what the hell I’m doing as a product manager, a story that I’m uniquely qualified to tell.

Some of my friends have written books, including Adam who wrote Football Clichés. He already had a successful blog and the book collated and improved his posts. I remember speaking with Adam at the time and he said that having his blog posts as a starting point was a huge help. I’m fortunate to be in a similar position, with blog posts stretching back for the last 7-8 years that will help me with early drafts.

I’ve started a newsletter as a way of chunking-up the drafting process. The first edition of the good product management newsletter went out to a hundred people on Friday. Many thanks if you’ve subscribed. Half of the distribution list opened it up within a few days, and it’s been opened over 600 times - which I’m guessing means it’s been forwarded on by a few people too. The next newsletter is being drafted and is likely to come out soon. Once it does, that means the bones of my introduction and first chapter are out in the world being tested. Sign up if you fancy getting an early look at bits of the book.

So it’s the end of the beginning of the book. I’m taking it slow and keeping it fun, hoping to draft a chapter every few weeks and see how it goes. Fingers-crossed.

Book Update: Pride and Prejudice and Moths

2020-05-11T00:00:00+00:00

One. The Moth

No one wants to speak. The organisers are walking the rows, hustling the audience for storytellers because the audience is also the act. Five people must agree to tell a true, personal story for the night to proceed. The month is February and the theme is ‘love hurts’. The host provides encouragement as the room fills up and a nervous energy builds. People grab drinks from the bar before things start. One by one, five people sign-up to tell a personal story of love to a room of strangers. The stories are intimate, surprising, rough around the edges, and brilliant.

Moth Club takes place monthly-ish around the world, with a regular slot at the Rich Mix in East London. A host, a location, and a theme are provided by the organisers but members of the audience provide the entertainment. Moth Club is a celebration of storytelling in its purest and simplest: entertaining people by taking a true, personal story and spinning it into a yarn. It’s also a chance to get immediate feedback on a story. If you’re writing a short story and want to improve it, there’s no better way to do this than by reading it out loud to people and seeing their reaction. That’s the lesson that I’m going to take from Moth Club when writing my book.

I’ve got a baby, I’m back at work, and we’re in lock down. I’m not going to do a lot of writing for the next couple of months, and I’m not going to put myself under pressure to do so. But writing my book is the last and the smallest aspect of creating my book. I can share my ideas out loud, see the reaction, and improve them before I document them in the book. I’ve helped people with their own writing. They often want a chance to talk about their ideas out loud, and for me to listen to them and share what I took from them. I’ll try the same thing for myself. Right now, making time to speak with like minded people sounds pretty good. The moral here is that I can develop my book by talking and sharing with others.

Two. Pride and Prejudice

I fell out of love with a topic half-way through a postgraduate degree in it.

I studied for a Master of Arts in critical theory, which aims to reveal and challenge our power structures by assessing our society and culture. I’d taken a Bachelor of Arts in English Studies, loved the critical theory modules, and gone straight into a postgraduate course specialising in the topic. This was my error: I should have taken a break between undergraduate and postgraduate study instead of going from one to another. As it was, I became jaded by such academic, abstract language* being used to describe such immediate, pressing issues happening in the world today. I started to use my essays as a way to argue against my chosen subject and in favour of a more accessible, emotionally-ground way of talking about power.

In one of my essays, I started with a book about power** and found it was excellent at calling-out power structures that tell us who we should be to the point where we internalise these labels. What I didn’t find was hope. There was no means of resistance to these power structures. I then moved onto another book** and found hope through resistance. It suggested that when we’re told that we are something or someone and we don’t recognise ourselves in that pigeon hole, we are resisting a power structure. However, it took me around a month to understand just one of the key chapters in this book, so dense and almost mathematical was the language. I ended by looking to Pride and Prejudice by Jane Austin and finding that it achieved something similar to the two other books, highlighting power structures and offering ways of resisting them, but did this through an accessible and emotionally grounded-story.

I did a few talks in 2019 and spoke with people for ideas for talks in 2020. Feedback from event organisers and attendees was that my personal stories worked well. They made abstract concepts personal by providing a real life context. Personal stories also worked well because they showed that I was making it up as I went along. They helped me curb the urge to present tidy packages of knowlege when in reality it often took me years to figure something out and it was only useful for a few months. I’ve also learned that sharing how I figured something out can be more valuable than the thing I figured out. The moreal here is that there’s always room for abstract thought but a little humanity will bring it to life.

Afterword

Sat here in 2020, * I don’t believe that critical theory is flawed because it uses academic language to describe abstract concepts, I’d just been doing too much of it for too long and needed a break from it. The two books were ** Discipline and Punish: The Birth of the Prison and *** The Psychic Life of Power: Theories in Subjection. I’ve massively reduced their arguments to fit into a few lines in order to cram them into a post about writing a product management book.

Book Update: Maelstrom

2020-03-30T00:00:00+00:00

It’s been three months since my last post.

‘Maelstrom’ is a great word. This is the first occasion I’ve had to use it appropriately.

A maelstrom is a whirlpool of extraordinary size, or a turbulent situation. Likely, it’s derived from early dutch words meaning ‘to grind’, and ‘stream’.

The last three months have felt like an extraordinary whirlpool at times.

A global pandemic has appeared, taken root, and taken over. We’re all indoors, living off a diet of TV, films, and takeaway. It’s like being in my 20s again.

Happily, I became a dad in January. A tiny, small human has appeared, taken root, and taken over. Life is about sleeping, feeding, and ignoring housework. It’s like being in my 20s again (badum-tish).

Into this whirlpool I have poured my ideas for a book on product management. I’ve jotted-down ideas that have occured in snatched moments. I actually made it out of the house to test ideas with human beings in the flesh in January and February. Thoughts reworked, connected, and discarded. It feels as though something has started to emerge from the churn.

I shared my intent to write a book in my last post, here’s an update.

Working title: Product Thinking

I think that ‘product thinking’ means something to a wider audience than ‘product management’. Organisations without a product management profession have asked me discuss ‘product thinking’, in general terms. Writing a book about product thinking for a relatively broad audience is more appealing to me than writing a book on the specialism of product management for an audience of product managers (which would feel like preaching to the converted).

Motivation 1: Ten-year review and retrospective

I saw a bunch of ‘ten-year review and retros’ at the end of 2019 and found them fascinating. My own attempt kept spiralling into a huge ‘thing’ that was not blog post-friendly so I ditched the idea for a while. The probable reason is that the 2010s is the decade in which my product management career took off, so there’s a lot to unpack. Also, product management and product leadership remain new-ish in their current incarnation so there’s been a lot of making it up as I’ve gone along. This created a lot to review and retrospect. A book feels like a better space to do this.

Motivation 2: Growth

There’s a thin line between analysis paralysis and running a feature factory. Too much research and your product stalls. Too many features and your product becomes bloated at the expense of actually gaining new users.

I think the same might be true of career development. I spent the first half of the decade researching, testing, and developing my core product management skills. And the second half of the decade filling gaps left by existing training and guidance.

Implementing the stuff I’ve figured out, at scale, is a 2-3 year project. Minimum. There’s no point in me figuring out new stuff. It’s time to release the value of the stuff I’ve created already. That’ll be a focus of the day-job when I return from parental leave. It’s also a motivation for this book.

Writing and publishing

Several friends, colleagues, and acquaintances have written books on topics ranging from product management, to cliches in football, to Russian propaganda postcards. And topics in between. I paid attention to their experiences of writing at the time, particularly because their experiences and approaches were so different. I’m going to follow-up with some of them to learn more about their approach to writing, and to learn more about publishing.

Stories

Personal stories seem to be a good way of bringing product-thinking to life. I’ve had repeated feedback from my talks that stories explaining how and why I came to a conclusion are interesting and useful. Honesty that we’re all making it up as we go along reduces barriers and empowers. I’ve learned that how I figured something out is sometimes more useful than what I figured out. So in addition to principles of product-thinking, I’m planning on adding honest, personal stories of how I made up those principles based on stuff happening in the real world. Often based on taking a couple of existing things, smashing them together, then adding/taking to the detail. Much like I do with BBC food recipes.

These personal stories circle-back to the working title of ‘product-thinking’ and a desire to review and retro the last decade. I started off with an instinct that we should ask people about their lives before we build something for them. And then found some stuff to help me do that. The specialist box of ‘product manager’ didn’t really ‘click’ for at least a couple of years. I’m interested to explain product thinking with limited jargon, using plain-ish English. Simplicity is hard and is the true test of understanding something. I’ll go on to talk about product management and product leadership using specialist terms, but want an accessible bedrock underneath.

Let me know if anything in this update struck a chord - it’d be helpful to hear your thinking on any of the above. I’m pondering where to create a separate site & mailing list for the book and associated updates but for now will keep it simple and keep it all here. Stay safe out there*.

*indoors

2020 Vision: Be a good dad, write a book

2020-01-06T00:00:00+00:00

‘2020 vision’ was the name of lots of vision statements and strategies I worked to in the early 2000s. I’d wager that most of them are now deleted from existence. Or gathering digital dust on long-forgotten network devices. People liked the pun and found the fact that 2020 was so far away appealing. Well, 2020 is now here. A 2020 vision finally means something :) Here’s mine:

in real life, I’m going to try and be a good dad. My daughter’s due to be born in a couple of days. It’s exciting.
in work life, I’m going to try and pull together what I’ve learned in the last decade. It’s time for a review and retrospective to see what I can learn.

Being a dad

My daughter’s due to be born soon. Me and my partner are really excited. This is our first child so we’ve been in learning and prep mode for the last few months. We’ve decided to share parental leave straight down the middle, taking 6 months each. My 2020’s going to be about learning to be a dad. I worked in parent advocacy at the beginning of the decade so it’ll be nice to revist that.

This will be the longest I’ve been away from work for a long time. I’ve been working since I was 13, starting out in retail on Saturdays. I took a break for a couple of months in my first term of university. Aside from that, this will be the longest break in my career. It’s going to be weird. But now feels like a good time. My career’s in a good place and I can focus on real life for a change. Shared parental leave is a privilege that I’m grateful for. Me and my partner are looking forward to meeting our daughter :)

Writing a book

I’m still going to think about my career in 2020. Between nappies and coffee I’m going to crave some ‘grown-up’ thinking. ‘2020 vision’ has got me thinking about corporate strategy. And how most of the ones I’ve seen in my career haven’t seemed to connect with the reality of what teams are doing. For all the innovation, vision, and strategies in the world, I’ve found two things to be true:

our products mirror our organisation chart
we’re defined by our existing commitments.

I’d like to help product managers in complex organisations with their existing commitments. I’m on version 3 of the handbook for my product management profession. The handbook’s weakness has been guidance for associate product managers. And guidance for product leaders. So it’s been great to work with Jon Foreman at GDS over the last 18 months to improve both of these areas. Simplicity is hard and it’s taken a few tweaks to convey some of the core concepts. Having now tested and improved the handbook for a while, it seems to be in a decent place.

Now feels like the right time to pull together a product management book. I can take my handbook as a starting point and edit it whenever I’m looking for 20-30 minutes of grownup thinking. I also want to do a review and retrospective of the last decade of my career. Real, influential moments of my career will help to bring hard won lessons to life, for myself and for others. I spoke at a conference in November and shared three real stories from the last 10 years. They included challenge and failure, as much as success. I enjoyed preparing for the talk, it helped me to clarify thoughts that’d been swirling around for a while. I’ll return to some pivotal moments in my life as a product manager in the 2010s and see what I can learn from them.

I’m not going to stress about the book. If it happens, it happens. Irrespective, the thinking about the book is appealing to me. Whenever I have the head space and motivation, I’ll do a little bit. And I’ll get out of the house and have coffee with product manager folks every now and again. And pester people who’ve written a book to see what I can learn from them. If that adds up to a book of my own, then great. If it doesn’t, then I’ll be still be returning to work as a better Head of Product once my parental leave comes to an end.

But first, baby

Book takes back seat to baby. Work life is important but real life is more important. I’m not going to be as active on this blog for a while, and won’t be as responsive to Twitter and LinkedIn messages for a while. Unless you’re sending parenting tips :)

My favourite books, films, TV, and videogames in 2019

2019-12-14T00:00:00+00:00

Books and films

In which I mainly read and watched horror, science fiction, and supernatural stuff. 2019 wasn’t necessarily the year they were released or even then first time that I watched/read it - but it was enjoyed this year none the less.

Books

A lot of anthologies, and a focus on cosmic horror, cyberpunk, and dystopian sci-fi. Favourites include:

Burning Chrome by William Gibson
Camp Concentration by Thomas Disch
Fire by Elizabeth Hand
Her Smoke Rose Up Forever by James Tiptree Jr./Alice Sheldon
The Moth: All These Wonders by Catherine Burns
The Best Horror of the Year, Volume 11 by Ellen Datlow.

Films

TV

Bonus, Podcast: The Case of Charles Dexter Ward.

Videogames

I’ve now officially given-up on AAA games in 2019, almost exclusively playing indie games. A lot of adventure/exploration. Some surprisingly touching games here, like The Gardens Between, Gris, Night in the Woods, and North.

Food

Very few fancy restaurants this year, we’ve been enjoying the same brunch-spots and takeaways as last year. We’ve been enjoying ramen this year, favourite spots being Shoryu in Stratford and Men on Chatsworth Road.

Product Leadership

2019-09-01T00:00:00+00:00

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

John Cutler on agile transformation
Melissa Perri on agile transformation and leadership
Why Enterprise Agile Teams Fail by Sam McAfee
Why Sainsburys’ Agile Transformation Keeps Failing by Joel Robinson
Understanding Fake Agile by Steve Denning
The End of Agile by Kurt Cagle

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:

make sure you have a vision
overcommunicate clarity, at least 2 levels down
delegate until you feel uncomfortable and then delegate some more
to encourage hones views, start by asking the most junior opinion and then work your way up the group
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.

How I blog

2019-08-05T00:00:00+00:00

I’m a blogging-geek. Having read and written them for many years, I remain excited by blogging and social media as a whole because they have removed barriers to publishing and democratised access to speach and information. I’ve previousy shared why I blog. Here’s a post about how I blog.

Inspiration

Writing can be daunting. I don’t sit down with a blank page and the desire to write a post. I have lots of options floating around in the background. Some are undeveloped, others are well-developed. I capture inspiration when it strikes so I’ve got a bunch of options at all times.

Professional challenges, product problems, leadership challenges, and interesting new ideas are always swirling around in the back of my mind but it’s hard to do something with them at work. The size and complexity of the organisation I work in and the pervasive communication tumbling through Slack means that I switch context many times a day.This makes reflective thinking difficult. To counter this I walk to work at least once a week (ideally a couple of times a week).

I live in Homerton and work in St James Park so the walk takes around 90 minutes. I’m normally listening to music but am otherwise undistracted, enjoying the walk itself. A weird thing happens most days: as I walk along Fleet Street and approach the Royal Courts of Justice on the strand, an idea will pop into my head. A problem I’ve been thinking on for a while will resolve itself. A couple of previously unconnected trains of thought will usefully converge. It’s very cool. Turns out that the most productive tool might be walking. I then switch to a more traditional productivity tool and make a note of the idea in Google Keep.

Alternatively, I sometimes read books on commute to work. The concepts are often familiar or I may be rereading something so I can often skim for useful points rather than reading slowly for depth of understanding. Perfect for public transport. If an idea or concept is particularly useful then I take a photo with my phone and save it in Google Photos.

Inspiration can strike anywhere. The above examples list the two most common ways that I get and capture ideas but it can also happen after a chat with peers, challenge or success at work, or interesting insights from others.

Periodically an idea will become clear enough to expand. Brief notes in Google Keep and photos in Google Photos will be explored further in a Google Doc. These Google Docs sometimes become the bones of a post, funcitioning as a drafting process.

I typically have at least 10-20 ideas swimming around in the pool of my Google Apps. Many of them have been incubated for weeks, sometimes months. They’ve all been refined at least once or twice and several of them have been discussed a few times. All of this helps to figure out the angle that makes them intersting, and to remove the angst from writing.

Choosing a topic

Choosing a topic has been easier since I’ve had my pool of ideas. I simply wait until a topic is particularly interesting to me - or until it’s useful for solving a problem at work - or a specific opportunity crops-up to write for someone else.

In the past I assumed that every idea I had necessitated a blog post. The list of titles became a ‘to do’ list and so writing became a stressful chore. This approach isn’t fun. I’ve changed in the last few years and removed the anxiety. Now I view blog posts how I view products, prioritising the posts that are most valuable, useful, and feasible. The most useful lesson I’ve learned is to let things go. Thinking about something can be a reward in its own right and there’s no need to write a post. This leaves space to write only what is most useful and most fun.

Writing the post

A decade into writing blog posts and I’ve got a pretty consistent process:

open up my laptop and start listening to a Spotify playlist on my earphones.
coffee can help to focus on the task at hand, particularly when the idea is pretty well-developed.
posts are written in GitHub. GitHub is marketed as a tool for software developers. However, at its heart is a text editor with version control that’s great for drafting blog posts. I write in GitHub via my browser*, hitting F11 to maximise the editor to fill the screen so as to remove the distraction of the search bar and all the website that sit behind it.
write using Markdown, a way of using simple tags to tell browsers how to format my post when it’s published to the web. Tom Preston-Werner’s post explaining why he created Markdown is still online, called blogging like a hacker and is a great read. I love how publishing has been revolutionised by the world wide web
write until happy with the post, normally a single sitting of 30 minutes up to a couple of hours
for simple posts I pause, take a break, then check that the words make sense and review for spelling, punctuation and grammer
for complicated posts I’ll use Hemingway Editor to see what improvements I could make (thanks to Nabeeha for the recommendation).

I don’t agonise over the post. They’re normally written for me to figure something out. I’m writing about niche topics of interest to a relatively small audience so don’t need to worry about writing great literature. My goal is to get it out quickly, improving once it’s published.

Note: *I don’t use a text editor like Atom. I used to but I’ve natually tended towards editing using GitHub in the browser. Most of my posts are text-only and Markdown only. I like having to check spelling manually as it reminds me how to spell :) I use GitHub Desktop when writing posts that need images. You can see this post in GitHub here.

Publishing the post

I publish posts directly from GitHub using GitHub Pages and have done since 2016.

WordPress was my blogging platform of choice for years. After a while I wanted the ability to back-up my posts, something that was not always simple in WordPress. Three years ago I moved from a self-hosted WordPress website to GitHub for reasons outlined in this post and have not looked back.

GitHub Pages are powered by Jekyll which turns plain text into simple, static websites. This simplicity is what made them easier for me to backup, unlike the database-driven blogs I had on WordPress. Jekyll does the hard work, turning my simple Markdown files into a simple but effective blog published by GitHub Pages.

GitHub Pages is free. I used to spend £50-£100 per year on hosting but now get that for free. I run a simple blog on a niche topic read by hundreds of people a month, not thousands (or more) so don’t need to handle many concurrent users. I pay for my own domain but that only costs a few quid a year.

Originally I built my own website through which to view the blog, using HTML and CSS. GitHub Pages has moved-on since 2016 and now offers themes. I switched to a theme called Minima earlier in the year and no longer need to engage with code more complicated than Markdown.

Publicising the post

I keep publicity simple, using a Tweet on Twitter and a status update on LinkedIn to publicise my posts. My goal is a small number of engaged readers. My Twitter and LinkedIn accounts are carefully curated formed from people I have worked with or am working with (for the most part), people I trust and respect.

So what?

I’ve got Google Analytics monitoring my blog and can see that it’s been accessed by 1,617 unique browsers in 2019. Unique views is a proxy measure at best, a vanity metric at worst.

The act of writing a post is normally a reward in itself, as it’s helped me to figure something out. Folks who’ve read my posts are often kind enough to mention so, either through real world conversation or when chatting over email. This is the feedback I’m looking for. The kind people who take the time to mention that they’ve read a post helps to validate the contents of the post, particularly when it leads to a conversation that challenges or develops my understanding further.

How blogging helped me become a better product leader

2019-06-19T00:00:00+00:00

I’ve been working out how to develop as a product leader for the last few years. Blogging has been a critical tool in my development. This post summarises and shares the reasons I’ve found blogging to be helpful.

Context

I needed to work out how to develop as a product leader. Product leadership is a relatively new concept. There’s little guidance out there that’s ‘ready to go’.

To be more specific:

I’ve progressed from product management to product leadership
There’s some way to go until product leadership roles are understood and used to their full potential. ‘Senior Product Manager’ and ‘Lead Product Manager’ can sometimes mean ‘really busy product manager’ in practice. ‘Head of Product’ can sometimes mean ‘glorified people manager’ in practice.
I don’t have a product leader responsible for my support and development
There’s a lot of guidance and training on product management. There’s relatively little on product leadership.

Action

Leaders lead, and that means going first. The gap in guidance for product leaders is an opportunity to develop it for myself. Blogging has helped me to collect the lessons I’ve learned so I can use them in the future. Here are some of the ways that blogging has helped me.

Statement of intent (to myself and for myself)

I published posts conveying simple tips until late 2017, like ‘the five stages of applying the service standard to technical stuff’. I used a post in January 2018 to tell myself that I needed to start figuring out wtf product leadership means. This post summarises thinking begun in late 2016 when working with an agile coach on developing my product leadership skills.

Reflecting on things I’ve experienced

I’ve hoovered-up ‘stuff’, by accident or design, and used blog posts to help me make sense of them.

‘Stuff’ includes:

Coaching to improve my performance
Books on general topics that contain nuggets of wisdom relevant to product leaders
Meetups (Mind the Product’s leadership meetup; cross-goverment Heads of Product meetups; suppers and coffees with product peers from outside the Civil Service; cross-government product manager meetups, etc)
Coaching to help others improve their performance. I spend at least 2 out of every 5 work days supporting members of my profession. Every time I help someone else to figure out their problem I hear a fresh way to approach my own problems.

This ‘stuff’ gets mixed in the maelstrom of the working week and starts to make sense in the quieter moments. During these quieter moments I’ll make notes. These notes are re-written, re-worked over time. At a certain point it’s clear that there’s a theme worth thinking about in more detail. That’s often when I’ll start writing a blog post as a tool to reflect on some thing I’ve learned.

Looking for ways to conceptualise my observations

I found The Art of Business Value to be helpful. In particular, it helped me to think what value looks like when we don’t measure it through profit. I read the book over a couple of weeks on the way to and from work, taking photos of bits that I found particularly useful. I then turned these photos into notes in a Google Doc over another couple of months. My notes were rewritten over 2-3 months as I used bits of them at work, finding out what was useful in practice. This post finally emerged in March 2018, at least 6 months after I first read the book. It took months to distill a complex set of ideas into something I could start to use in a practical setting. A year later I simplified it further based on what I learned, publishing post called ‘how we can measure value without profit’.

There are limits to blogging but the discipline remains useful. Lean Enterprise contains valuable insights. I read Lean Enterprise in 2015. There was a free evaluation copy doing the rounds within ‘agile’ circles. The content didn’t sink in at the time. I decided to re-read it in March 2018 and this time it struck a chord. This time I could see it as a blueprint for how to work with agility at the scale of a large enterprise. I read it over a couple of weeks, and again I took photos of the most interesting bits. There were so many photos that it took me months to type them up. I had a 20-page booklet that I started to calling ‘lean government’. I could not find a way to shape this booklet into a single blog post, or even a short-series of blog posts. I still refer to my personal ‘lean government’ booklet but have failed to turn it into a blog post. In reality it has infused 10-20 practical projects at work. The discipline of wanting to blog helped me re-working my notes until they were useful.

Result

I can now explain what product leadership is, in simpler terms. This simple explanation will be the focus of a future post. Simplicity is hard-won. This blog has provided space for reflection. Reflection has helped me turn experiences it into lessons I can learn from. I have been the main audience for my blog posts over the last couple of years.

Learning

This has reminded me of my time in education. I worked on the ‘digital transformation’ of education in the 2000s. My focus was improving teacher training. My team funded digital tools to help trainee-teachers. These tools helped collection of evidence and reflection on experiences. I took a module in the Open University’s postgraduate course in online and distance learning. One aspect that I found useful was thinking of learning as several stages, that all need to happen if we’re to genuinely ‘learn’:

concrete experience
reflective observation
abstract conceptualisation
active experimentation.

This is known as David Kolb’s experiential learning cycle.

I have concrete experiences in my job and in my quieter moments I note observations. Notes grow over time. Sometimes my notes converge with concepts from reading or conversations I’ve had. This helps me to conceptualise my experiences and observations. My blog posts help me to pull this together. I can test my posts in practice, refining them based on how they work in the real world. My blog helps me turn experiences into lessons I can use in the future.

If you can relate to my context then I can recommend blogging as a way of helping you to develop as a product leader.

Who's got time for digital transformation?

2019-04-08T00:00:00+00:00

This is the fourth in a short series of posts about digital transformation’s need for business models, you can read the introductory post here.

Agile approaches added a time dimension where previously there was none […] The Waterfall model was based on taking a point-in-time snapshot of the information we know and using it to create a long-term plan that we would adhere to. The Agile insight was that we should change our notion of what features will create business value over time as more information becomes available […] Agile approaches added a time dimension where previously there was none.” The Art of Business Value, Mark Schwartz

The value of our work changes over time. We can start to understand this by defining at least two stages in the lifecycle of our products: (i) exploring new opportunities, and (ii) exploiting existing opportunities. Understanding that our product and their value changes over time helps us to refine the common assumption that ‘delivery is the strategy’.

‘Delivery is the strategy’ was the rallying call of digital transformation in government for the longest time. The truth is that ‘delivery is the strategy’ is a tactic. It’s something used at the beginning of digital transformation to build an organisation’s emotional confidence in a new way of working. This rallying call is often interpretted as ‘the delivery of stuff is the strategy’, because ‘stuff’ gives everyone confidence that things are happening. It’s a period of rapid investment in new opportunities. And it’s critical for the first 1-2 years of digital transformation, generating opportunities for the digital pipeline and demonstrating to colleagues that digital teams can be trusted with work. However, we quickly build up a lot of stuff that needs to demonstrate return on investment and be supported and maintained and have to figure out models for ongoing funding and continual improvement. It’s not uncommon to suddenly find too much work in progress and less return on investment than planned, with issues quickly arising.

There’s an increasing move to the notion that the era of move fast and break things is over, with the realisation that things can go worong when delivery remains the whole strategy beyond the the first 1-2 years of digital transformation. We are just realising that we need to go broader and deeper than ‘brand-new’ and ‘public-facing’, into the realm of ‘legacy’ and ‘staff-facing’. And even further than that: into the underlying business models by which we operate.

Does delivery remain the strategy, or is the era of move fast and break things over? The truth is that both things are required and need to coexist. The truth is that the era of lurching from one extreme to another is over. We absolutely need time and space to generate new opportunities in under conditions where we can move fast and break things. And we absolutely need space where existing opportunities are cared for and optimised under more stable and risk-averse conditions. We need to stop the all or nothing mentality that drives us to lurch from one extreme to the other. We need mutliple sets of conditions that co-exist, and to start using them strategically, where and when they are most useful.

Explore or exploit?

If we look at the lifecycle of a product, we can start by breaking it into two stages that help to balance new opportunities with existing opportunities. These stages are called ‘explore’ and ‘exploit’. Take a look at the table below for a summary of these stages, based on the summary in The Lean Enterprise.

—	Explore	Exploit
Strategy	Radical or disruptive innovation, new business model innovation	Incremental innovation, optimising existing business model
Structure	Small cross-functional multiskilled team	Multiple teams aligned using principle of mission
Culture	High tolerance for experimentation, risk taking, acceptance of failure, focus on learning	Incremental improvement optimisation, focus on quality and customer satisfaction
Risk management	Biggest risk is failure to hit product/market fit	A more complex set of trade-offs specific to each product/service
Goals	Creating new opportunities, discovering new opportunities within existing portfolio	Maximising yield from existing opportunities
Measure of progress	Achieving product/market fit	Outperforming forecasts, achieving planned milestones and targets

‘Exploit’ is the default of the Civil Service: a risk averse approach to incrementally improving existing opportunities. This approach does not work well for developing new opportunities. The Government Digital Service introduced the conditions for ‘exploration’ - this is what the service manual and phases of an agile project provide: a means of developing new opportunities. But this approach does not work well for ‘live’ opportunities. We need both exploration, and exploitation.

Product/market fit

You’ll notice that there is a tipping-point from explore to exploit, referred to as product/market fit. This concept is most commonly used in a commercial value context, where it kind of means the point at which we’re confident that a product is actually working in the marketplace, and we have the confidence to invest in growth of the product. However, we’ve previously established that we can measure value without profit, and that commercial concepts normally apply in public services with just a few tweaks. In the context of public services, we could take product/market fit to mean the mean adoption of our software by users in order to justify the cost of development. In this situation we would say that:

X number of people need to use our software in order to justify investment we’ve received
‘use’ is defined as completing the user journeys required for the software to be valuable
our one metric that matters during exploration is the % of our target adoption that we’ve reached
secondary metrics would be how long we’ve taken to reach product/market fit, and what % of our available investment we’ve spent to get there.

Notice that I use the word investment. We should revist our use of the word ‘budget’. We should seek investment based on the potential value of solving problems, over seeking budgets based on the cost of building software.

Three horizons

We can use the concept of having different conditions based on ‘time’ and use it to inform investments at a portfolio level. If we only invest in the shiny and new then we never reach the point of return on investment. If we only work on our existing stuff then we reach a point of intertia. We need to optimise the value of our current opportunities whilst still developing new opportunities. McKinsey’s three horizons of growth is an enduring model that gives us a way of thinking about this. In the below model, the ‘exploit’ phase is expressed as ‘horizon 1’. Horizon 1 represents the core business of our organisation, well-established and successful opportunities that generate our main return on investment. The ‘explore’ phase is broken into two horizons, ‘horizon 2’ and ‘horizon 3’. Horizon 2 represents emerging opportunities that are likely to be successful but which require significant investment. Horizon three represents ideas that might become opportunities down the road but are currently in the research phase.

These horizons can be used to help manage risk and increase the likelihood of return on investment/benefits realisation. The diagram below suggests a common use of this model to help balance a portfolio:

Horizon 1 (established opportunities) contains our best investment opportunities. Research has been carried out, large investment has been made, and we’re already seeing return on investment/benefits realistion. Investing in this space is likely to see return on investment within 0-12 months (so potentially within the same financial year as the investment is made)
Horizon 2 (emergent opportunities) contains future opportunities but that require significant levels of investment. Investing in this space remains pretty high-risk but is crucial if we’re to continue to grow as an organisation. Investing in this space is likely to see return on investment within 12-36 months.
Horizons 3 (ideas in the reseach phase) contains our riskiest investments, and our best chances to be transformational. Investing in this space is likely to see return on investment within 36-72 months.

We need all three horizons in our portfolio in order to optimise the value of our current opportunities whilst still developing new opportunities but we should not invest equally in each horizon. The below diagram shows a common spread of investment across the horizons in order to maximise return on ivestment whilst investing in the future:

Horizon 1 (exploit): 70% of available resources
Horizons 2 (emergent opportunities): 20% of available resources
Horizon 3 (research): 10% of available resources

Balancing a ‘digital’ portfolio

Remember we said that the phases of an agile project effectively gave the Civil Service a way of exploring new opportunities? We can use this realisation to think of the phases of an agile project as relating to to horizons 2 and 3.

We can think of discovery* and alpha (and anything that proceeds them) as research into ideas that might emerge as opportunities. This is horizon 3. We should probably invest around 10% of our available resources in discovery, alpha, and anything that proceeds these phases.

We can think of beta and the beginning of live as emergent opportunities. This is horizon 2. We should probably invest around 20% of available resources in beta, and early live phases.

Remember product/market fit? Well that’s the point at which an opportunity tips from exploration into exploitation. Which is the same as tipping from horizon 2 to horizon 1, according to our thinking in this post. We have a slightly odd situation where there is no service assessment to check if we ever hit product/market fit, or ‘benefits realisation’. The final assessment takes place at the end of public beta. It’s called a ‘live’ assessment but only because it gives permission to become ‘live’, not because it’s actually assessing that we’ve hit product/market fit. If we were to have a ‘product/market fit’ assessment, then passing it would more us into the exploitation phase, or horizon 1. This is where our lowest-risk, quickest return on investment is likely to sit. We should probably invest around 70% of our resources in this space.

‘Digital’ is often pitched as cost-saving, and this is probably true in the long-term in the long term (36-72 months). But when ‘digital’ is the answer for in-year cost-savings, and digital is being used to develop new stuff that’s starting in horizon one then we’re unlikely to see return on investment as measured by cost-savings in the desired time frame.

We have an ongoing debate within digital teams about whether discovery ever ends, or if it’s ongoing. Personally, I agree that research is ongoing throughout the product lifecycle. However I also agree with my colleague Nabeeha Ahmed, that not all research is ‘discovery’. I subscribe to Roman Pichler’s definition of product discovery as ‘finding out if and why a product should be developed’.

Prioritising activity within the ‘exploitation phase’ or ‘horizon 1’

Let’s say that we’re investing 70% of our resources in our core business, in our strongest existing opportunities. How do we balance the need for new features against the need to pay-down technical debt, for example? We steal an old product management tool and apply it at a large scale. Let’s take Barry Overeem’s prioritsation quadrant.

Our portfolio requires four activities to happen concurrently within exploitation phase/horizon 1 if our software is to remain evergreen and not become what’s commonly known as ‘legacy system’:

new features (responding to new insights or changing user needs)
improved support (software is only valuable if it’s used; our support model makes sure it’s used)
technical debt (maybe we originally hosted on privately and now we need to migrate to public cloud)
technical innovation (the work down to realise that public cloud is now a ‘thing’ and to see if we can make use of it, for example).

All of these activities need to happen concurrently in order to avoid technical debt becoming so massive that it becomes so massive that it swamps everything else, swallowing all investment and focus and becoming the sole focus for our organsation (possibly in the form of a programme). However, we are unlikely to invest in all activities equally. And the balance of investment in each activity can (and probably should) vary from one period to the next. What’s important is that, for the live software in our portfolio, all activities are happening concurrently at all times.

Retirement

There’s a point at which we can no longer justify investment in software on our portfolio. Maybe people have stopped using it. Or a commercial, off the shelf product has emerged that’s much more cost effective. Or we’ve found duplicate software elsewhere in our portfolio and can conflate two pieces of software into one. In any event, return on investment has dropped too low to continue with investment.

How do we know this. Returning to the starting point of this whole series of posts, we should understand the business model for each piece of software and our portfolio as a whole, and regularly review them. When the costs outweigh value, we need to take action.

Importantly: retirement can happen at any time during the product lifecycle outlined in this post. I used to teach at General Assembly and would tell students to expect that 7 out of 10 ideas should either be retired or significantly change through research and development. Applying the same logic to our digital work in government, we should expect that for every 10 ideas that begin in discovery, 7 of them should them should either be retired or undergo significant change before leaving beta.

How do we measure the value of software features of public services?

2019-03-20T00:00:00+00:00

This is the third in a short series of posts about digital transformation’s need for business models, you can read the introductory post here.

We’ve established that it’s possible to measure value when we’re focussed on helping people over profit, we just need to focus on public value over private value.

But public value is too big to be practical for me, from my position in the ‘digital’ bit of the Civil Service. I need SMART-er value that fits my bit of the world.

Measuring the outcomes of software

First a reminder: value is context specific:

“Value” is the most ambiguous word in business. It means something different to every person that says it, primarily based on where they’re positioned in an organisation. Defining value: the most ambiguous word in product development, Jeff Gothelf

I work on public services within the Civil Service as a ‘digital’ specialist, so this is the perspective for which is want to define value. This requires me to locate the small bit of public services in which I play a part.

The public value chain

It’s possible to view public services as operating at three levels:

Public service
1. End-to-end public service: A service helps a user to do something that needs to be done, and completely meets that need. It also helps government achieve policy intent on behalf of its citizens with whom it has a social contract. Services are best identified as verbs (visit the UK), rather than nouns (biometric residence permit).
2. Features of services: this is ofen where we (digital) work. Often the things we work on are just one step in a service, like ‘applying for a visa’ - a software feature of a larger, end-to-end service
3. Capabilities of features: these are the resources required to run the features of services. Examples include people, specialist tools, technology, and data.

Each level is critically dependent upon the others in order to provide an end-to-end public service since all are required for the overall value of an end-to-end public service. These three levels are the main links in the value chain for public services.

Public service	Value chain
End-to-end service e.g. ‘visit the UK’	Impact e.g. number of peope who visit the country legally increases
Features of services e.g. ‘apply for a visa to visit the UK’	Outcomes e.g. time taken to successfully apply for a visa decreases
Capabilities for features e.g. ‘digitisation’ project team	Outputs e.g. visa application process is ‘digitised’

The definition of public value in the previous post is particularly relevant for people who have to work out overall impact, like executive agencies and policy teams. But as we’re about to see, outcomes for software can be somewhat impact-agnostic. Yes, our digital software needs to support this impact. But the needs met by public-facing software are often broadly similar, and the needs met by staff software are often broadly similar. They may be used to achieve differing impact, dictated by the mission of the sponsoring Department. But the outcomes of the software can potentially be measured in a shared, consistent way.

It’s possible for the links in a value chain to become invisble or even break all together. A logic model can help to restore a value chain when this happens. Theory of change are the most common type of logic model used in situations such as these but aren’t without criticism, with system-mapping tools like Wardley Mapping increasingly used to map out value chains.

From my perspective working witin a ‘digital’ team in the Civil Service, I’m typically working on the software features of end-to-end services - looking at the above value chain, we can see that value in this context is defined by the outcomes of that software has for the users of the software: measurable changes in user behaviour that contribute towards the overall impact that our Department would like to have.

The value of digital transformation is currently measured by the outcomes of software

OK, we’ve taken a long journey and arrived at a conclusion. Value from my perspective is likely to mean the outcomes of the software features of end-to-end public services, measured through changes in user behaviour that contribute towards the overall impact that our Deparment would like to have.

Value of staff software

For my own organisation, the majority of our portfolio can be described as ‘staff software’: software for our colleagues to help them do their jobs. This is broadly described by the term ‘business to business’ software.

It’s possible to say that busines to business software meet three main needs:

Doing daily admin
Making better decisions
Complying with bureaucracy

We can measure the extent to which these needs are being met through measures like:

Time taken
Capacity
Failure demand

As a starting point, the above needs and measures could help us to create a common language for defining the value of staff software in the Civil Service.

The video of Roan Lavery’s talk at Mind the Product 2018 is a great place to explore value in a B2B context in more depth.

Test out the above with your most challenging staff services, where we’re often told that it’s difficult to measure value.

Let’s take hosting or infrastructure. We often consider hosting or infrastructure platforms to be ‘technical’, and may even hire ‘technical’ product managers. In reality, hosting and infrastructure are capabilities, they are ‘outputs’. If we think differently and instead think of it as a platform to run and change software then the outcome we’re looking for is to make it quicker and easier to change software. We might achieve this through things like: certificate management (daily admin), testing software iterations before publishing (making decisions), and maintaining the security of data (complying with bureacracy). All of these can be measured through ‘time taken’ (which might be measured through number of steps required). All can be measured through failure demand (e.g. incidents). And improving any or all of them can improve the capacity of an organisation to make changes within fixed resources.

In theory, this would work for ‘consultancy’ work too. In situations where we act as experts in a particular field (like service design, user-centred design, working with agility etc) for internal customers/clients/users, we’re still trying to help them with daily admin tasks/making better decisions, and complying with bureaucracy. So my assumption is that some variation on the above would work for things like our support for programme design, procurement, and policy design.

Value of public software

My own organisation also has a significant amount of public-facing software. I find this harder to desribe as simply as staff software, because we meet more varied and complex needs in this space. So I need to go very general as a starting point.

Very broadly speaking, I think that the most common public-facing software in my organisation and across the Civil Service is ‘apply for a thing’: a webform that allows a member of the public to apply for a public service. This is not the only thing we do by any means, but my starting assumption is that the is the most common and significant thing we do.

Talking about value is tricky here, as it’s arguable that application forms to meet a true user need, since very few users ever say ‘I really want to have to complete an application form before accessing a service that I believe I’m entitled to’. Government has a need to check that the publis is genuinely entitled to public services they wish to access and this is the main need being met. The user need is probably something like ‘make the application process as simple as possible, with as little ‘friction’ as possible’. The Service Standard’s manadatory KPIs provide a good way of measuring how well these needs are being met:

Completion rate
User satisfaction
Cost per transaction
Adoption

In fact, we could take this further and start measuring a single score worked out something like the following:

User Value Score = {Adoption*(Completion rate + User Satisfaction)}/Cost per application

This could work at multiple levels. E.g. For an individual online application form, adoption is the % of people who use the online option. At Department level, adoption is the total number of people who apply for services online (which will be inhibted until forms are digitised). At Government level, adoption is the number of people who apply for services online (which, once again, will be inhibted until forms are digitised).

We can measure the value of software for the public, and for staff

So we’ve checked-in with ourselves and found that the Service Standards’ mandatory KPIs remain a good way to measure the value of transactional public software, and found a way to measure the value of staff software. We’ve recognised that the outcomes of software needs to be tied in to the overall impact our end-to-end services are supposed to have, which is likely to support the overall mission of our Department. Although the impact and missions of our Departments may vary a lot, it’s possible that we can think about the outcomes of our software in a common and consistent way. So we’re sorted?

Not quite. Finally, we’ll talk about how value changes over time in the next post in this series (coming soon).

How do we measure value without profit?

2019-03-19T00:00:00+00:00

This is the second in a short series of posts about digital transformation’s need for business models, you can read the introductory post here.

The principles of Agile Manifesto say that value is the most important thing to focus on. But then forgets to explain or define value. We need to plug this gap and figure out what value means for us, so we can check that the stuff we’re building through build-test-learn feedback loops is truly valuable.

We have an additional challenge when doing this within the Civil Service because we’re not foccussed on making a financial profit. People I speak to get stuck on this assumption that value can only be measured financially: how can we think of value when we’re not focussed on financial profit or return to shareholders?

Value is missing from digital transformation

Value is the most critical aspect of working with agility. It’s the focus of the first of the principles behind the Agile Manifesto. If we were to tweak the Agile Manifesto for Software Development so that it works better as am Agile Manifesto for Public Services then the first principle would be that:

Our highest priority is to satisfy the public through the early and continuous delivery of valuable public services.

‘Digital transformation’ is about helping organisations to work with agility, and focussing on value is one of the most important aspects of working with agility. Except that 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 seem to assume that ‘value’ is figured out somewhere else by ‘the business’ then presented to delivery teams in a fully-formed stated to be consumed and acted upon. In reality, it’s often the case that ‘the business’ is waiting for delivery teams to present their defintion of value. And so we can end up in a space where we’re all delivering ‘stuff’ early and often without an honest sense of whether it’s truly valuable.

Working with agility makes the promise of focussing on value but then witholds the means by which to define value. This is a tricky state of affairs for a product manager because our focus is on managing value. We are responsible for the outcomes of our products and services. It’s the role of the product manager to define the value of their products and services - so that’s what I’m going to try and do :)

“Leaders create the language of the organisation; they set up incentives and define value in a way that elicits the descired outcomes. They define what is valued in order to deliver on the organisation’s mission.” The Art of Business Value, Mark Schwartz

The main principle I need to remember is that value is context specific. Trying to define ‘value’ in the abstract is a fool’s errand. I work on public services within the Civil Service as a ‘digital’ specialist, so this is my context.

Public value

Value in a commercial setting is commonly understood. When the context is ‘commercial’, we’re all familiar with measuring value through things like profits or return to shareholders. We can think of this as ‘private value’.

Lots of guidance on thinking about value is focussed on private value. This can lead us to assume that value is not relevant for public services. But with a few tweaks, we can apply most of it to our context. Understanding the differences between private value in a commercial setting and value in public service helps us to understand the tweaks needed to unlock existing guidance measuring value.

The Civil Service is not a commercial setting so profit or return to shareholders are pretty usefuless ways of measuring our value. Our goal is satisfy the public’s needs through public services, so our context is public value.

How do we measure public value? Public value is defined as two things in the context of public service delivery by the Civil Service:

mission value: achieving the mission of your department as well as possible whilst hitting financial targets for liquidity
political value: maintaining the trust of the public in Government

Mission value

Non-profits measure their value through the extent to which they achieve their mission whilst also meeting financial targets for liquidity. In practice this means doing as much as possible towards their mission within their budget, and trying to increase their budget if they can see the need to do so.

Mission value usefully describes the main priority for everyone in the Civil Service: our main goal is to achieve our mission as well as possible whilst also meeting financial targets for liquidity. Every Department has a different mission, and its important for each Department to specify how the success of their mission will be measured. What’s our one metric that matters (this might change from reporting period to reporting period but it’s important to have one at all times)? What are our other key performance indicators? What’s the benchmark for these metrics at the beginning of the financial year? By how much do we need to improve them by the end of the financial year in order to justify the investment that the public has made in our mission? How do we know if we’ve succeeded or failed?

Political value

Things aren’t as simple as that because these public services are delivered through Government. I’m privileged to live in a liberal democracy with a parliamentary system. We also have a constitutional monarchy. These social systems are the foundation of our society and critical for our country to continue to run as it does. This means that it’s important to maintain the trust of the public in these social systems, something that we define as political value.

Political value may not be clearly expressed to us but is often disclosed by bureaucratic rules.

“You find that the government is always in the public eye - the press is always reporting on government actions, and the public is quick to outrage [. . .] [so] government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness [. . .] Blame is quickly assigned within public services so government is highly risk averse, placing high business value on things that mitigate risk.” The Art of Business Value, Mark Schwartz

Good bureaucracy helps maintain the trust of the public in our critical social system and so delivers value.

“When an agile team self organises to meet business needs and deliver business value, it cannot just consider customer and user needs for its products. It must consider all of the needs of the organisation and all of the things the business values, and then self organise to meet all of those needs. The needs disclosed by bureaucratic rules are amongst those needs.” The Art of Business Value, Mark Schwartz

Mission value should outweigh political value

Sometimes it can feel as though policitcal value contradicts mission value. How can we test if this is the case, particularly since political value may not be clearly expressed? The answer is not to get lost. The needs of the public remain paramount and the majority of public value should always come from mission value. We have things like the Civil Service Code to help guide us, and remind us that we must have integrity, honesty, objectivity, and impartiality. Although it is true that civil servants are accountable to ministers, ministers have their own code which stresses that, “Ministers must uphold the political impartiality of the Civil Service, and not ask civil servants to act in any way which would conflict with the Civil Service Code.”

The needs of the public should always be the main focus of our work. We should be able to objectively say that at least 51% of the value of our work is defined by how well we are meeting our mission for the public. We should also acknowledge that maintaining the trust of the public in our core social systems is valuable and a worthwhile endevour. We can always check-in with ourselves and ask the simple question: are we doing good?

We can measure the value of doing good

We’ve established that we can measure the value of public service, and that we can call this public value. We’ve acknowledged that lots of guidance on figuring out value is focussed on private value and geared towards commercial settings. But now we know that if we tweak this guidance, contextualising it for public value, we can make use of it in the Civil Service. We’ll use these principles in the next couple of posts which are about how to measure the value of the software features of public services, and how value changes over time (to be published soon).

Digital transformation needs business models

2019-03-17T00:00:00+00:00

There’s something missing from digital transformation.

The commonly used defition of ‘digital’ within UK government is:

“applying the culture, processes, business models, and technologies of the internet era to respond to people’s raised expectations.” Tom Loosemore

It follows that ‘digital transformation’ of public services requires the transformation of culture, processes, business models, and technologies. However, it could be argued that we’re focussed on the transformation of technology. Spend controls and service standard have had a huge impact on culture and processes of government (albeit mainly within the digital/technology ‘bits’ of government). What strikes me is that transformation of business models remains conspicuously absent from digital transformation to date. I have an assumption that transforming business models would help us to bring together pieces of digital transformation to date, creating a whole that is more than the some of its parts. Specifically, I think that business models will provide focus on two important perspectives: (i) value; (ii) time.

You can find my take on what a business model means in practice here.

Value

Digital transformation is often a way of describing attempts to get a large organisation to work with agility. The first principle of the Agile Manifesto for Software Development is that increasing value is our highest priority. But the Agile Manifesto forgets to tell us how to figure out what’s valuable. Subsequent frameworks based on the Agile Manifesto (like Scrum) also assume that ‘value’ is figured out somewhere else, and focus instead on telling us how to deliver ‘stuff’ through ever more efficient build-test-learn feedback loops.

Transforming business models requires us to figure out if our ‘stuff’ is actually valuable:

Our first challenge is to figure out what ‘value’ means in public services, where our focus isn’t generating profit or generating a return for shareholders - read about how to measure value without profit
Our second challenge is to figure out how to measure ‘public value’ when working on ths software features of public services - read about how to measure the value of software here

Time

Value means different things during the lifetime of a product and this is critical for thinking about how we make investment decisions in software features of public services. Transforming business models requires us to figure out how we manage risk to outcomes through understanding characteristics of the software features of public services as they age. Our challenge is to understand that software products require different delivery conditions throughout their lifetime and to stop thinking that we can have one-size fits all organisational conditions - read about how value changes over time and how we can use this to help balance a digital portfolio here.

Espresso yourself: eight-years of making espresso at home, in one post

2019-02-16T00:00:00+00:00

I recently threw out some old receipts and was suprised to find that I bought my first espresso machine eight years ago - it made me realise that I’ve come a long way since those first bitter, watery attempts back when the UK was starting prepartion to host the Olympics. Here’s what I’ve learned about making espresso at home over the last eaight years: what to buy, and how to use it.

Why espresso?

There are loads of reasons why you shouldn’t bother making your own espresso at home but for me it’s my go-to coffee. Espresso is thicker and has more concentrated flavours than most other types of coffee and you can drink a couple of them because they contain less caffeine than other types of coffee (caffeine is more concentrated in espresso than other coffees but the overall small volume means there’s less caffeine in total. I also enjoy the simple fact that I can make decent espresso at home - it’s something that lots of people don’t have the kit, the patience, or the practice to do - so I take pleasure in making it, and friends enjoy the novelty of drinking it.

Coffee beans

Coffee beans have different flavours based on a bunch of factors like where they’re grown, how they’re grown, how the flesh of the coffee cherry is removed from the coffee bean, and how the coffee beans are roasted. There’s no such thing as the ‘perfect’ coffee beans, that’s just clickbait to get you to read an article - the ‘perfect’ coffee bean is simply the one you most enjoy.

The factor that’s often had most impact on my choice of coffee bean (and the kit I need to make my espresso) is how the coffee is roasted. I was at Spa Terminus in London a few years back and got talking about coffee roasting with a coffee roaster called Jack Coleman - I’d just had a go at roasting my own coffee and the results had been rubbish. One of the things that Jack explained to me was that coffee has two ‘cracks’ when it’s roasted: the first ‘crack’ is the first point at which you’ll get drinkable coffee - before this point the coffee beans remain green and produce undrinkable coffee; the second ‘crack’ is the last point at which you’ll get drinkable coffee - after this point you’ve got burned coffee beans and the coffee will taste like ash. This is the scale for coffee roasting - first crack is the lightest roast possible - second crack is the darkest roast possible. The ‘Italian’ style coffee beans we get in the UK tend to be towards the darker end of the scale, where you’re tasting the roasting process along with the taste of the bean itself (this is why it can sometimes taste bitter, and why Italian-style espresso sometimes benefits from the addition of sugar to sweeten it) - in my experience, dark-roasting helps to produce a more consistent end result than light and medium-roasted beans - and seems to be what the entry-level home expresso kit (often created by Italian companies) can handle pretty well. However, my natural preference is for the ligther-roasted coffee beans where I can taste more of the bean itself and more of the natural sweetness of the coffee cherry - I never need to add sugar to this type of espresso. In my experience, the downside to light-roasts and some medium-roasts is that the results are less consistent than dark-roasts so there’s more of a need to fine-tune my espresso kit to get decent results - somethings that’s not possible with the cheapest, most entry-level kit.

I’ve had a few favourite roasters over the years - Nude Espresso, Monmouth Coffee, Workshop Coffee, Allpress - but what they’ve got in commmon (other than selling really nice medium/light roasted espresso beans) is that they were in some way local to me at the time of buying - either near to my home, or on the way to work. We’re spoiled for good coffee roasters in the UK and in lots of towns and cities there are excellent coffee roasters within a few miles of home. I currently drink Square Mile Coffee’s espresso blends - the coffee beans are excellent - the roastery started in Hackney (my home borough of London) - and it’s stocked in my local coffee shop, 46b Espresso Hut, so I can easily buy it when I need it.

My experience of coffee beans designed for espresso is that they tend to be a blend of a couple of types of coffee beans. I’ll be honest - I have no idea why this is. If I had to guess? Espresso is really intense - some beans have all the flavour ‘up front’ with nothing to follow, whilst some beans are more subtle and take longer to register their flavour - so maybe a mix of the two creates a good balance. But as I say: I don’t really know, so take that with a pinch of salt :)

Coffee grinder

The quality of your espresso is really dependent upon the quality of your coffee grinder.

First of all: buy whole beans and grind them yourself at home, and only grind them when you need to use them. Coffee beans are a foodstuff - they’re the beans from coffee cherries - and will go stale eventually. This takes ages as roasted coffee beans - you’ve got several weeks - but takes just hours once they’re ground. So grinding your own beans, just in time to make your espresso, makes such a positive difference to the taste of the finished drink.

I started out with a DeLonghi grinder in the £40-£50 price range. DeLonghi is an Italian company so it makes sense that their grinder works well for dark-roasted coffee beans. However, I could never get it to work consistently well for medium or light-roasts and eventually I upgraded to a Sage Grinder in the £150-£200 - I’d been making espresso for years by this point so was sure that I’d get a lot of use for it, but it still felt like a lot of money to spend on a coffee grinder. My anxiety eased upon use, however, as the coffee beans I’d had iffy results from in the past suddenly tasted amazing - the ability to fune tune settings made a massive difference. You’re unlikely to be able to spend less than £40-£50 on a grinder if you want to make your own espresso at home but can get decent results from this price range if you tactically choose the right coffee beans - but investing at least £150-£200 in a grinder will open up way more options.

Broadly speaking, I’m looking to tweak the settings of my grinder to help get to the flavour of the beans - and the exact settings very bean to bean, and crop to crop. At its simplest, I’m often thinking: ok, if this tastes weak or watery then maybe the coffee has been ground too large and the water is running through it too quickly so I need to grind it a little finer and start again; or maybe the espresso tastes bitter because the coffee beans are ground too finely, the water is sitting in the coffee grinders for too long and over-extracting the coffee, so I need to grind a little coarser.

Tip to get you started: Using the Sage Grinder to grind the Square Mile Coffee, I’m often grinding to a setting of ‘10’.

Water

Espresso only has two ingredients - coffee and water - with water being the main ingredient by far, so it’s worth making sure it’s decent water. What makes decent water? In my experience, it’s how well the water allows the coffee to dissolve into it. I live in London which has ‘hard water’ - which means that it already has lots of solids dissolved in it (hence looking chalky) and is not great at absorbing additional solids, like coffee. A water filter is a great investment if you live in a city like London, since it will remove some of the solids in the water, increase the amount of coffee solids it can absorb, and improve the flavour of the espresso. Using filtered water also has the benefit of reducing the speed with which limescale builds up in your espresso machine, reducing the amount of services it needs and extending its lifespan. Living somewhere with very ‘soft’ water, I’d assume it’s fine straight out of the tap. You can buy mineral water if you want to go super-fancy but I’ve never been bothered to do this.

Espresso machine

So you’ve got 3 main options when choosing an espresso machine: manual, semi-automatic, or automatic.

A manual espresso machine has a lever that you manually pull down in order to get a shot of espresso - hence the phrase ‘pulling a shot of espresso’. I have never met someone who has manual espresso machine. They look cool and there’s a certain charm to how basic they are but the videos I’ve watched suggest there’s a lot of skill and effort required to get even decent results, and the machines have real limitations to what you can do with them.

At the other end of the scale there are automatic espresso machines that do pretty much everything for you - you pour in water, coffee beans (and milk, if wanted), press a button, and it does the rest. These are great if you want consistently decent espresso without any effort - and trust me, this is not to be sniffed-at - but you’re unable to fine-tune the kit to get the best from specific coffee beans so the best you can get is ‘decent and consistent’ (which, once again, is not to be sniffed at). Nespresso machines are an extreme type of automatic espresso machine - I’d assume their business model is that they can subsidise selling the machines at a loss by locking you in to over-priced coffee capsules for the lifetime of the product.

I’ve got a semi-automatic espresso machine, which means that I don’t have to manually pully down a lever (the machine pushes the water through at pressure on my behalf) but I do need to grind, measure, and press (or ‘tamp’) the coffee grinds myself and time the shot myself (and foam milk myself if wanted). This takes skill and practice - there’s no way around this and it would be dishonest to pretend otherwise. It took me a few months to start getting decent results, following a couple of lessons - and I don’t think I was getting really good results (on a par with some coffee shops) for a year or so. If you don’t have the time or interest to learn a new skill and practice that skill then a semi-automatic espresso machine is a bad choice and I’d suggest an automatic espresso machine instead.

My first espresso machine was a DeLonghi Icona which can often be picked-up for around £100 on Amazon. This was a great way to learn and pracice without spending lots of money, whilst I was still learnig the basics. Eventually I hit the limits of the machine and upgraded to a Gaggia Classic. I got mine for £180 in 2012 but oddly they’ve gone up in price and now seem to cost £200-£300. I think that automatic espresso machines have become the market leader in the last ten years, possibly because of the popularity of capsule espresso machines, and semi-automatic machines are more of a niche market. Whatever the reason, there’s not a massive range of decent semi-automatic espresso machines below £1,000. If you don’t like the look of the Gaggia Classic then the main alternative seems to remain the Rancilio Silvia that can sometimes be found in the £500-£600 price range.

One of the reasons I like the Gaggia Classic is that it’s got a portafiler that’s 58mm in size - the same size as many commercial machines in coffee shops - which means it’s relatively easy to get spares, replacements, and modifications. The Gaggia Classic I bought shipped as standard with a shallow poratfilter basket (the thing that holds the coffee grinds) which only allows you to make a single espresso) but I was able to buy a new, deeper basket capable of holding more than enough coffee grinds to produce a double espresso for £5-£10.

I treated myself to a new portafilter a year ago - a ‘bottomless portafiler’ which doesn’t have spouts, for £35. The practical purpose is that is creates more space underneath the portafilter to make it easier to move my espresso cupes in and out whilst creating espresso shots - helpful for me because I rest the espresso cup on small digital scales in order to measure the weight of my shot. An unexpected bonus is that it makes it easier to see how well the espresso is flowing from the machine.

Eventually your Gaggia Classic will get clogged-up to the point that it requires a service - in my case it took 5-6 years. When this happened I was able to find a bunch of excellent, helpful vidoes online that told me what to do - this Youtube video is the one I used most - and just required a special kind of cleaning basket + cleaning powder that I got for £10-£20 from Doppio.

Tip to get you started. The question you need to ask yourself, if you want to make your own espresso at home, is: do I want a hobby, or do I just want a decent espresso at the weekend? A manual or a semi-automatic espresso machine is a hobby that requires time and effort - with the reward being potentially excellent results. An automatic espresso machine is a consumer device that gets decent results at the touch of a button - with the reward being consistent results with little or no effort.

Acccessories

There’s some other bits that I use every time I make espresso. I use standard digital kitchen scales to make sure that I start with the right amount of ground coffee - I zero the scales with the empty portafilter + basket, grind the coffee diretly into the basket and portafilter, then weigh again to check I’ve got the right amount (I often brew my espresso with 18g-19g ground coffee, depending on the beans I’m using). I’ve also got micro scales that I use to measure the weight of the espresso as I’m making it - I zero the scales with the espresso cup on them and normally pour the espresso until I have a double-shot of about 28g-30g (depending on the coffee) - there’s normally around and extrate 3g-5g of weight by the time the flow has stopped. The microscales means that they’ll actually fit in the small space under the portafilter.

The espresso cups I favour tend to be on the shorter end of the scale so that they’re easier to get in and out of the machine (versus taller ones, which can catch on the portafilter). My current favourites are these from Kaffeeform, made from discarded coffee grounds.

Finally, a coffee tamper is critical in order to compress the coffee grinds and create a flat, even surface (both so that water doesn’t pass through the coffee grinds too quickly, or pass unevenly through the coffee grinds), and a knockbox is really helpful for emptying out the used coffee grinds - before having one of these I kept accidentally dumping the basket into the bin.

How do I actually make the espresso?

Using my Sage Grinder to grind Square Mile espresso beans, I will normally use grind setting ‘10’ and set the timer to grind for 15.4-15.6 seconds, which will normally produce approx. 18g of coffee grinds (sometimes it’s too much and I just remove a little at a time until it’s the right amount). I’ll tamp with a medium firmness, then run the espresso machine until I’ve got 28g-30g, stopping and expecting a further 3g-5g to come out as the flow stops. Here’s a photo of the results you’ll get using this method.

This isn’t the ‘perfect’ espresso (no such thing, this is a clickbait title), it’s what gets results that fit my tastes using the beans and kit I own. Use the websites, Youtube channels, and classes I’ve recommended at the end of the post to learn more about espresso and figure out what method gets a flavour that you like.

Milk

I often like to have milk with my espresso and frequently make myself a flat white at the weekend. The steam wand that ships with the Gaggia Classic is bad - if you want to steam milk with any kind of decent results then you’ll need to replace it with a better steam wand from a different machine. Once again, Youtube came to the rescue - I found and used this video, and replaced it with a spare Rancilio Silvia steam wand that I bought for £20-£30 (I think). Be warned though: this type of modification will void your warranty, if you break something then it’s up to you to fix it (or to pay for it to be fixed).

Tip: if you want to use vegan milk then I’ve found that Oatly barista edition gives the best results whilst being widely available in supermarkets. You’ll get results decent enough to do latte art with - here’s a photo of a recent flat white.

Helpful places

I’ve been helped a lot over the year by the kindess and insights of strangers, including: Coffee Forums UK has great advice on modifying and using espresso machines at home; Seattle Coffee Gear’s Youtube Channel is a great way to find out about kit and see it in action; and James Hoffman’s Youtube Channel is a great way to find out about how to make coffee and coffee trends (from one of the people behing Square Mile Coffee).

A couple of classes have helped me over the years too - the craft and science of esprtesso at the Department of Coffee - and the introduction to espresso and milk at Workshop coffee.

Espresso yourself

I think that’s it. Eight-years of ‘self-taught’, trial and error, home-made espresso - guided by the kindess of strangers and a couple of classes from experts, distilled into one long post. I hope it’s useful.

If it’s convinced you that espresso is too much like hard work or too expensive to make at home - that’d be a sensible conclusion! My kit would probably cost at least £500-£600 to buy from scratch in one go in 2019, and realistically takes at least a few months and a lot of practice to get to grips with. If that’s not for you then you can create amazing coffee much more simply using lower-tech methods - here’s my guide to brewing coffee using French Press, filter, and Aeropress - or support your local, independent coffee shop (£2.50-£3 for a flat white suddenly sounds more reasonable, right?).

If it’s convinced you that making espresso at home using a semi-automatic machine sounds nice and fun, then join the club :) My Gaggia Classic is seven years old and built like a tank - I’m expecting another five-ten years out of it, and it’s nice to understand enough about the machine to get good results from it and to look after it. It’s really enjoyable to make espresso as good as you might find in some decent independent coffee shops (and better than most chain coffee shops). If you’re willing to put in some time and money, it’s a hobby that can give you and your loved ones pleasure every morning.

Be prepared for the emotional impact of introducing psychological safety

2019-02-12T00:00:00+00:00

This is a quick post about what happens after the introduction of psychological safety - my experience of the weeks and months following its introduction, and the emotional preparation you need to make as a leader introducing psychological safety.

Psychological safety within a group

You’re probably already familiar with the term psychological safety if you’re reading this post - my take is that we should all be able to turn up to work as our true selves without fear of negative consequences, and that we should feel able to to constructively honest in our interpersonal relationships within groups at work . . . and organisations that foster this kind of psychological safety typically foster high-performing teams. The label of ‘psychological safety’ was famously used by Google and subsequently popularised in the last four years but has been around for much longer than that. Google’s definition of psychological safety is, “team members feel safe to take risks and be vulnerable in front of each other”.

Individual trust

I really believe in psychological safety. I’ve tried to introduce it several times, in several organisations, at several scales - and hope that I’ve been successful in at least a few of these attempts. The guidance and blog posts on the topic didn’t prepare me for one thing: the introduction of psychological safety can open the floodgates for individuals who may not have felt safe or listened to for a long time - and as the person introducing this psychological safety you may become a person that individuals trust - and with this trust comes a responsibility to support people on a 1:1 level - sometimes with big things.

Psychological safety itself is about safety within a group, not about 1:1 trust - but by introducing this safety, I became a person of trust - and the first couple ot times, I wasn’t prepared for this.

Following the introduction of psychological safety I’ve had weeks, sometimes months of intense 1:1s as people bring more of themselves and their honest problems to our time together. Big personal things. Big professional things. Tears. Burnout. Weeks, months, sometimes years of ‘stuff’ that’s finally getting an outlet. Some of this ‘stuff’ will be brought out within teams/groups that have fostered psychological safety but some of it needs a trusted 1:1 and you might be called on to provide that trusted 1:1. Real life is messy and the professional veneer of an office hides all sorts of massive life events going on all around us, all the time.

What I’d like to say to you if you’re about to embark on the introduction of psychological safety for a group at work is - do it, it’s awesome. I’d also like to say that you should be prepared that success might also bring trust in you as an individual - and that you should be prepared for this, and earn that trust. You will hear about issues and may need to support people in ways that make you feel uncomfortable. You will get Friday afternoon emails/messages/calls appear week after week in which someone is asking for your help with something hard. And you will find this emotionally challenging, as it’s hard to hear about people in bad situations. But if you’re serious about psychological safety then this is a sign of success - so please be prepared.

This comes full circle - I think that the thing I’ve most improved over the last ten years or so is making sure I have my own psychologically safe groups in which I can share these challenges and ask for help.

Through the other side

My experience is that there’s a point, after a few weeks or months, where the initial, intense period starts to even-off. The weeks/months/years without enough safety begin to disappear as the pressure is released through healthier professional relationships. The safety wtihin teams/groups grows and the need for trusted 1:1s diminishes and starts to fall into more of a regular rhythm.

I’ve held onto the idea for this post for ages - I’m not initiated psychological safety for a little while now and wanted to write this post when I’m not in the midst of it. So a message to my future self the next time I’m doing this would be:

psychological safety is always worth the effort
but it is a lot of effort
be prepared for trusted 1:1s with you to be an essential part of developing group safety, for up to a few months
make sure that you have your own safe group and trusted 1:1s during this time
and remember that after a few months or so you can expect to see changes that will make you happy.

Associate Product Manager Program Blueprint

2019-01-03T00:00:00+00:00

I’m working with several others to improve the experience of Associate Product Managers in government and wanted to see what we could learn from outside government. Lots of organisations have Associate Product Manager prgorams and I found a list of them at the Product Managment Insider in a post called The 15 Best Associate and Rotational Product Manager Programs by Suhas Motwani. The design of these programs was extremely similar so I’ve created an Associate Product Manager Program Blueprint based on the common features of some of the based programs out there. Hope it’s of use!

Label: Associate Product Manager Program

Goal: To develop future product leaders, often ‘from scratch’, using ‘rotations’, mentoring, and a strong community to accelerate development

Duration: 12-24 months

Format: Cohorts of APMs (ranging in size from 4-5, to 40-50) undertaking 2-4 ‘rotational’ placements

Candidate characteristics: University graduate (possibly from subjects like computer science, business, or psychology) and existing professionals with expertise in a relevant field.

Core features and benefits of program:

Rotational, with 2-4 rotations during the program that are agreed between the APM and their main point of contact for the program
Mentoring, from multiple perspectives, for example (1) an alumni advisor, who is a seasoned PM who used to be in the APM program; (2) a buddy, who was an APM a year ahead; (3) one-on-one sessions with a management coach
Trips or bootcamps, for example 1) 5-10 day APM trip/bootcamp, possibly across several locations) to learn about successful products, or technologyies in different markets, understanding local users 2) Mini-trips/bootcamps: single day/single location to learn more about a single user-type or industry of interest
Planned activities like books clubs, tech conferences, social events
The APM community itself should be one of the main benefits for many APMs if the program is successful., providing a network of contacts for support and opportunities through their careers.

End result: Associate Product Managers ‘graduate’ to full Product Manager if they successfully complete the program.

What is product management in government?

2019-01-02T00:00:00+00:00

The job of a product manager is to discover a product that is valuable, useable, and feasible. Product management is uniquely responsible for the value (aka benefits, aka outcomes) of products because it operates in the intersection between user experience (UX), workflow, technology, and business goals: passionate about solving problems but usefully flexible about the specific solution, providing guidance through a focus on the end goal (aka value/benefits/outcomes). Product management provides a generalist perspective amongst specialists, and is defined by its relationship with others. Product management is unique amongst the professions in that it works simultaneously with delivery teams, and executive management teams.

How does product management work within delivery teams?

Delivery teams require four different perspectives if they are to create valuable, feasible, user-centred products as a high-performing unit:

Value
Workflow
User Experience (‘UX’)
Technology.

What do we mean by each of these persepectives?

Value: Product management brings a perspective on value above all else, focussed on maximising business value from a product. Product managers should be primarily focussed on optimising a product to achieve business goals while maximising return on investment.

UX: Professions such as user research, business analysis, and design provide the perspective of users to the team, leading the understanding of users, the problems they face, and the way that products work in the real world. UX professionals should be focussed on talking to users, testing the products, and getting feedback first-hand above all else.

Technology: Professions such as software development, technical architecture, and web operations provide the perspective of the ‘makers and doers’ to the team, leading the understanding of the possible solutions to the users’ problems. Technology professionals should be focussed on improving the quality of their solutions through build-test-learn feedback loops above all else.

Workflow: Professions such as delivery management provide the perspective of output, leading the overall performance of the team and helping value, UX, and tech professionals to work together. Workflow professionals also lead on the team’s understanding of broader constraints and dependencies.

How does product management work with executive management teams?

Product management supports the business function of its organisation, helping to align the goals of products to the goals of the organisation - in order to do this, product management need to provide their delivery team with the perspective of their organisation, and looks to the organisation’s management teams to provide these goals. The interplay between executive management teams and product management represents the difference between business strategy and product strategy.

Business strategy	Product strategy
“How will the business succeed?”	“How will the product succeed?”
Led by executive management teams	Led by product management + product teams
Clear, measurable, outcome-driven goals for what the organisation is to achieve	Clear, measurable, outcome-driven goals for how products will achieve the organisation’s goals
Empowers product management + product teams to own the product strategy	Trusted to figure out how to achieve the organisation’s goal by management teams

Product management supports executive management teams in setting a business strategy and business goals that are feasible by advocating for the perspectives of their delivery team; once set, product management advocates for these goals within their delivery team.

Product management = Value

Product management acts as the intersection between the goals of the organisation, and the perspectives of their delivery team - it’s at this intersection that products become their most valuable, and so product management leads on value.

Product management is defined by its relationship with with others:

Within a delivery team, product managers are generalists amongst specialists, aligning multiple perspectives into a clear product strategy and goals
Within executive management teams, product managers bring the specialist perspectives of their delivery team to help influence business strategy and goals to improve their value and feasibility - then take these goals to their delivery team.

What is product management not?

Product management is commonly confused with project managementment - possibly because both professions are abbreviated to PM :) Project teams are temporary organisations where the solution and plan has been decided and the goal is to follow the plan successfully to the goal - projects are great are a great option for a delivery model in situations of high-certainty in a problem and high-agreement in a solution (this is the opposite of product teams, where only the outcome and resources are known - solution and plan are flexible and develop as we learn more).

Product management can also be confused with application owner or technology owner. Outsourced software or technology managed through pre-planned and agreed service level agreements requires an owner. These applications or technologies are products, and have owners/managers, so the in-house manager may be confusingly referred to as product owner or product manager - but is not fulfilling the role outlined in this guide - instead they are performing a different skilled and valuable role that is needed across government.

What does product management look like?

Product management is a relatively new profession within government, requiring a broad set of skills and understanding of multiple other professions - as shown in the previous section. All of this combines to make product management a difficult profession to learn without doing - meaning that’s it’s difficult to take a course or degree that will provide everything required to lead a product from day-one on the job - many product managers will tell you of the circuitous journey into their current role. This journey will begin by learning the tactics of product management, and then learning product management strategy.

Product management tactics

Product managers often begin by developing their product management tactics - taking the large goals outlined in the product strategy and breaking them down into SMART-er goals (specific, measurable, achievable, realistic, time-based) for their team (this is often called the product backlog) - the team will turn these goals into actionable tickets. The product manager will lead their team in planning and reviewing product increments in the format of rapid build-test-learn feedback loops (often known as ‘sprints’).

Product management strategy

Product managers move onto leadership of product strategy once they have mastered product management tactics. Product strategy involves:

understanding the problem to be solved, and the conditions under which it is valuable to solve, feasible to solve, and pervasive, urgent, and valuable enough to make it worth solving - this is often expressed in its simplest terms through a ‘value proposition’, and then explored in more detail via business modelling
building a vision that describes the desired-future-state, including value/benefits/outcomes needed to justify investing in the product
running a ‘roadmap’ that promises value improvements/outcomes/benefits (but does not commit to specific features/solutions), connecting the problem as it stands today with the vision for how it will look in the future.

Product strategy is ‘live’ and should be reviewed at least once per month - it is not a static business case developed once, at the beginning of a product - it is a group of changing insights and conditions summarised in several strategic tools that help us to respond to change in a way that maintains the value of our products - or (ideally) to improve the value of our product over time.

Product management career pathway

A team is a team is a team. Product managers require the same tactical and strategic skills throughout their career. The specific implementation changes a little when moving from delivery team, to middle-management team, to leadership team - but the general principles remain the same. This is at the heart of the product management career pathway - the tactical and strategic expectations remain consistent but the scale and complexity changes.

Associate Product Manager: Associate Product Managers begin with an awareness of product management and are expected to develop, through doing, until they become become a product management practitioner and graduate to full Product Manager. This journey will begin by learning the tactics of product management, and then learning product management strategy. Associates are ready to graduate to full Product Manager when they are a practitioner of product management tactics and strategy, capable of leading an entire product and product team on their own.
Product Manager: Product Managers lead the product tactics and strategy for a product.
Senior Product Manager: Senior Product Managers lead the product tactics and strategy for a group of products that share a value proposition. Senior PMs focus on the total value of the group of products, helping them to operate in relation to each other. This might involve re-prioritising one product in the group over another at times. Senior Product Managers are likely to be managing the product managers in their group. Senior PMs are likely to remain ‘hands-on’ in one more more products but may be working with Associate Product Managers who will pick up the product management tactics for individual products. Some Senior PMs may remain at work on a single product that is particularly complex or challenging - this is where we make most use of contractors, for example. However, they will need to move into the way of working outlined above in order to develop the expertise required to progress to lead product manager.
Lead Product Manager: Lead Product Managers lead the product tactics and strategy for an entire business-unit, product-line, or end-to-end service. This might involve re-prioritising one product group over another at times. Lead Product Managers are a member of the management team for their product area, and are responsible for the overall performance and recruitment of their product community in their product area - ‘hands-on’ product management within delivery teams is likely to disappear as this approaches and exceeds ten product managers; there will be an increasing amount of work with their middle-management team. This represents the shift from ‘product management’ to ‘product leadership’.
Head of Product: Head of Product supports/facilitates the product tactics and strategy for the organisation as a whole. This involves working closely with Portfolio & Controls through things like Triage, Prioritisation and Service Assessments. This might involve suggestions for business-units to explore shared opportunities that cross organisational boundaries. This is achieved by working closely with Lead Product Managers and their business units. Head of Product is responsible for the overall performance and recruitment of the product management profession, working closely with Lead Product Managers on this.

Product management handbook

All of this is explored in more detail in the Product Management Handbook with exaplantions, suggested reading, and useful courses.

Influences

Richard Banfield, Marting Erikson, Nate Walkingshaw, Product Leadership. O’Reilly, 2017.

Roman Pichler, “Why product people should care about business strategy”. Roman Pichler, 2018.

@lissijean (Melissa Perri), @joshuajames (Joshua J. Arnold), @tastapod (Dan North), “Delivery team perspectives”. Twitter, 18 February 2018.

Martin Eriksson, “What, exactly, is a Product Manager?”. Mind the Product, 2011.

My favourite films, books, TV, videogames, comics, and places to eat in 2018

2018-12-12T00:00:00+00:00

Films and books

I’m currently enjoying science fiction, horror, and ghost stories (but you’ll find other genres too). 2018 wasn’t necessarily the year they were released or even then first time that I watched/read it - but it was enjoyed this year none the less. There are a lot of films below - the two that have probably stuck with me the most are Daphne & The Transfiguration.

Films

Books

Artificial Condition (The Murderbot Diaries #2) by Martha Wells
Black Static (bi-monthly anthology of horror short stories)
The Best Horror of the Year Volume Seven edited by Ellen Datlow
I, Robot by Isaac Asimov
The Quiet American by Graham Greene

Television

Altered Carbon
Ash vs Evil Dead (Season 1)
Handmade
Great Canal Journeys
Hannibal (Seasons 1-3)
The Haunting of Hill House
Inside No. 9
Iron Fist Season 2
Luke Cage Season 2
Parks & Recreation (all seasons)
Rich Hall’s California Stars
The Rules of Abstraction with Matthew Collings
Silicon Valley Season 4
Ugly Delicious
What do artists do all day?

Videogames

I pretty much gave up on AAA games and online games in 2018, mainly playing single-player games I could complete in 4-8 hours.

Comics

Promethea Volumes 1-5 by Alan Moore
Persepolis by Marjane Satrapi

Food

I live in Hackney and tend to like neighbourhood joints (mainly for weekend brunch or lunch):

I also head into Central London every now andd again for fancier food, my three favourites from 2018 were:

Choosing a coffee brewer

2018-11-17T00:00:00+00:00

I came to decent coffee about six years ago and wanted to make it myself at home. It was difficult to get plain English advice on the difference between the ways of making coffee so I ended-up buying them all and learning through trial and error. Here’s what I learned, I hope it helps you to start right.

Simple brewing methods are the easiest and cheapest way to get started with making decent coffee at home because they let you learn the basics without committing to a lot of kit. How do you choose which simple brewing method is right for you? Start with the type of coffee you prefer to drink.

Strong flavours, maximum caffeine hit

The French Press (also known as cafetiere) that lots of us have lurking at the back of a cupboard is a great way to produce strong coffee with maximum caffeine. This is because the ground coffee is fully immersed in boiled water, dissolving solids and extracting a lot of the stronger flavours into the drink. You can find more help with brewing coffee using a French Press here.

All-rounder

The Aeropress produces well-rounded coffee, and is a sturdy bit of kit (so good for travelling). The ground coffee is fully immersed in water (just like the French Press) but is then pressed through a filter paper, which removes some of the stronger flavours and solids and leaves you with slightly more delicate flavours. You can find more help with brewng coffee using an Aeropress here

Delicate flavours and less caffeine

A coffee filter (also known as dripper) produces delicate coffee that’s close in appearance to tea. Water is poured through ground coffee and passes through filter paper, extracting only the most delicate flavours, removing a lots of the solids, and leaving you with less caffeine then the other methods. You can find more help with brewing filter coffee here.

Product roadmaps and me

2018-09-30T00:00:00+00:00

I’ve now been working in government for over three years and product roadmaps have been a recurring theme. Not surprising, given that I’m a product manager? Well no - but the real reason they’ve been such a recurring theme is that I’ve found the humble product roadmap to be the ‘face’ for product management as a whole. Government contains lots of product managers who’re new to product management - and lots of product managers who’re new to government - and lots of people who’re new to the concept of product management. The product roadmap often becomes the site for exploring and explaining product management as a whole, for better or for worse.

So, in January 2017, I ran a session at the cross-government product meetup about what had worked and what hadn’t worked when attempting a portfolio-level roadmap in government. The later post referring to my session generated requests for help from other government departments who wanted to introduce or improve their use of product roadmaps, so much so that I wrote a follow-up post for the Government Digital Service, sharing simple tips for using product roadmaps. Once again, this generated multiple requests for help from other government departments (and a Local Authority) . . . so I started work on further support for roadmaps in the form of a diagram of a ‘good’ roadmap, with notes to explain the core concepts at play. I tweeted a picture of version 2 of this diagram that once again got a bunch of responses, including a suggestion to draft something for Mind the Product - which you can see here.

That’s probably as many posts as I can usefully write on the topic - but if you’re a government department, government delivery agency, or local authority and would like a chat about roadmaps then please feel free to get in touch on Twitter.

Another reason why product managers are not like CEOs

2018-09-25T00:00:00+00:00

We’re all familiar with the trope that ‘product managers are like mini-CEOs’ that became popular in the last five-years or so - here’s an example of an article from The Next Web that put the trop to use in 2013. The counter-arguments are starting to emerge too, like Martin Eriksson’s article from 2017 entitled Product Managers - You Are Not the CEO of Anything. This post is another reason why product managers are not like CEOs - in short because we need people like CEOs to give us goals so we can do what we do best: figure out how to meet those goals.

Where did the product manager as mini-CEO trope come from?

Ben Horowitz wrote a famous memo over twenty-years ago in which he referred to the product manager as the ‘CEO of the product’. That same memo is published online but now has the following disclaimer:

“This document was written 15 years ago and is probably not relevant for today’s product managers.”

Product Marketing for Technology Companies by Mark Butje (2005) also refers to product managers as CEO’s - but with a significant caveat:

“The product manager is a weird person - someone who takes on an enormous amount responsibility without actually being in charge. Sort of like a CEO but without the hierarchic power.”

I think this is interesting and rings true. CEOs are in charge and have power. We (product managers) are not in charge and do not have power. We have influece but not authority.

The important difference between business strategy and product strategy

What is ‘power’ or ‘authority’ in this context, and why don’t we (product managers) hold it?

The answer may lie in the difference between business strategy and product strategy. Roman Pichler’s recent article - Why Product People Should Care About Business Strategy - summarises this well:

“Business strategy - how will the business succeed? Product strategy - how will the product succeed?”

A good CEO owns business strategy - setting the vision for what the business will achieve and providing the basis for making the right investment decisions.

A good product manager - in this case probably a product leader like a Head of Product or a Product Director - sets the vision for how business’ products will support the business strategy.

“The business strategy states how the company will be successful, whereas the product strategy describes how […] product[s] will achieve success.”

A good CEO does have overall ‘authority’ for their organisation as a whole - in that they own the overall business strategy. We (product managers - even the most senior product leaders) influence our organisation through product strategy - how our products support our overall product strategy.

And that is another reason why product managers are not mini-CEOs.

Afterword

The Lean Enterprise gives some great tips on how an organisation and its leaders can use both business strategy and product strategy.

Financial Times’ talks on its use of the principles similar to those outlined in The Lean Enterprise are useful in helpig to understand what this looks like in reality. Here’s a talk by Cait O’Riordan (Chief Product Officer) and another talk by Bede McCarthy (Product Director).

What is an end-to-end public service?

2018-05-14T00:00:00+00:00

Government digital teams in the UK build public services that are genuinely valuable for the public, which is awesome. There is an increasing focus on ‘end-to-end services’, with the word ‘digital’ becoming less prevalent as we realise that software is not the beginning and end of public services - so much so that the Digital Service Standard is becoming the Government Service Standard.

Two very enthusiastic thumbs up.

This all sounds good . . . but what is an end-to-end public service? Do we all mean the same thing when we say end-to-end public service? Helpfully, some clever people have provided us with a definition. Louise Downe and Kate Tarling have created a great starting point for us to understand what an end-to-end public service is that I’ve been using for the last year or so (thanks both!).

Here is a summary of Louise and Kate’s work, in the form of three principles to help us understand what an end-to-end public service is - I’ve made a couple of tweaks so that it fits my context but it’s mainly a copy, paste, and summary of two of their posts.

Principle 1: A service helps a user to do something that needs to be done

To a user, a service is simple. It’s something that helps them to do something - like learn to drive, buy a house, or become a childminder. It’s an activity that needs to be done.

This isn’t always how government sees a service. Government sometimes sees services as discrete transactions that need to be completed in a particular way, like ‘Statutory Off Road Vehicle Notification (SORN)’.

‘Learn to drive’ describes a service. ‘Statutory Off Road Vehicle Notification (SORN)’ describes a transaction.

Adapted from Good services are verbs, bad services are nouns by Louise Downe, Government Digital Service.

Principle 2: A service name starts with a verb

A core principle of Agile and Lean theory is that services should seek to maximise value. Services should be judged not on their adherence to cost and delivery schedules, but on their delivery of value.

When a service name starts with a verb like ‘Learn to drive’ it tends to focus the attention on value. It describes a thing a user needs to do.

When a service name starts with a noun like ‘Statutory Off Road Vehicle Notification (SORN)’ it tends to focus on a transaction. It describes something the government does.

Adapted from Good services are verbs, bad services are nouns by Louise Downe, Government Digital Service.

Principle 3: Use the term ‘service’ accurately and sparingly

Some of what UK government refers to as services aren’t really services. ‘Learn to drive’ is an end to end service. The elements needed to learn to drive probably think of themselves as services in their own right. However, none of them independently meet the overall need to ‘learn to drive’. So they are not a service, they are a part of a service, or a ‘feature’ of a service.

Services

A service helps a user to do something that needs to be done. It also helps government achieve policy intent on behalf of its citizens with whom it has a social contract. Services are best identified as verbs (visit the UK), rather than nouns (biometric residence permit).

The following are not services - they are things that help to build services:

Features

Often the things we work on are just one step in a service. These are called features, and examples include:

applying for a visa
applying for a licence
granting or refusing permission.

Capabilities and activities

A capability is having all resources required to carry out a task – such as skilled staff and specialist tools – and also considers capacity and maturity. Appointment booking, for example, is a capability that requires:

an appointment booking system, which may be a technical capability
physical locations or phone support to host the appointments
a process for changing or cancelling appointments.

Activities are the things people do in relation to using a service, including:

finding out how something works
calling people for help
applying for something.

Technology

‘Technology’ means the digital systems, products, tools, hardware and applications we build, maintain and buy. Technology exists to support activities and capabilities – and enables us to deliver faster, clearer, simpler services.

Data

Data means the actual information that’s either generated by or used to carry out activities and services. Use descriptive words for data, such as ‘National Insurance number’, and avoid acronyms.

Adapted from Creating a common language to describe services by Kate Tarling, Home Office.

You can suggest corrections and improvements or request clarification by at my Github repo or by getting in touch on Twitter.

How to brew coffee using an Aeropress

2018-03-03T00:00:00+00:00

This is how I make a 250g of coffee using an Aeropress. An Aeropress combines immersion brewing with filter brewing and is a good compromise between the lightness of filter coffee and the robust flavour from a French Press. The Aeropress itself is a hardy bit of kit, making it great for travel. A hardy plastic cylinder and plunger, the Aeropress was invented by the same guy who came up with the Aerobie (the circular, frisbee style toy from your youth). Your Aeropress will come with filter papers, a funnel, and a paddle for stirring.

Kit

water filter
Aeropress
filter paper
Hario Mini Mill Hand Coffee Grinder
Salter digital scales
funnel
kettle
stirrer
mug
timer

Ingredients

coffee beans
filtered water

Method

Boil the filtered water and leave to cool a little (pouring boiling water on ground coffee will burn it)
Place a filter paper in the Aeropress cap and screw it to the cylinder, then place it on the mug and rinse the paper with some of the boiled water (this prevents your coffee from tasting of the filter paper)
Measure 17g of coffee beans into the grinder and grind them (note 1: The guidance is 6g coffee beans per 100g of coffee, making 15g coffee beans for a 250g mug, however this is only a guide and should be tweaked for personal preference. I seem to get my best results from 17g coffee beans. Note 2: To measure the coffee beans, I place the grinder on the scales without the arm or the lid but with the funnel in it. I then zero the scales and pour out the beams. This prevents the beans from going all over the place)
Pour the rinsed water from the mug. Once the boiled water has cooled, place mug and Aeropress cylinder on the scales, pour in the ground coffee using the funnel, then zero the scales
Pour 250g water in to the Aeropress, stir with the paddle, then place the plunger in the top (this will create a vacuum and prevent the coffee from filtering though)
Start the stop watch and let the coffee brew for 2 minutes before slowly pressing the plunger. Stop plunging when you hear a ‘hiss’, just before you’ve completely pressed it down
Leave the coffee until it’s cool enough to taste, then drink.

Leadership dimensions: value management

2018-03-02T00:00:00+00:00

In which we realise that working with agility focuses on delivering value but forgets to figure out what value is; product management finds a place to help figure out what value is; and we acknowledge that value is context specific so we figure out what it might be in government.

WTF is value?

A while ago I wrote a post based on the assumption that business strategy is in its infancy, with Simon Wardley saying that ‘organisations often rely on meme copying and gut feel’. Why is this?

One reason might be that the Agile Manifesto talks about value being our highest priority . . . but forgets to define what value is or how to figure it out. Most of the stuff I’ve read that’s based on the agile manifesto also forgets to define value. So what we’re left with is some great guidance on how to build valuable stuff . . . but little help to figure out what ‘value’ is.

The art of business value

The Art of Business Value by Mark Schwartz is the first book I’ve read that attempts to put the fill the ‘value’ gap in the Agile Manifesto. As Mark says:

“A core principle of Agile and Lean theory is that software development should seek to maximise business value. Projects should be judged not on their adherence to cost and schedue milestones, but on their delivery of value to the enterprise. Value should be delivered as quickly as possible - in small increments - and features should be prioritised based on the amount of value they deliver […] The Waterfall model was based on taking a point-in-time snapshot of the information we know and using it to create a long-term plan that we would adhere to. The Agile insight was that we should change our notion of what features will create business value over time as more information becomes available and, in fact, that it can be worth an investment even just to incrase learning, thereby reducing uncertainty and opening a space in which innovation can occur. Agile approaches added a time dimension where previously there was none. But the meaning of business value itself was a given […] known to the business, and that is not good enough.”

In short: we know that working with agility will help us to ‘deliver value’, but it won’t help us to figure out what value is.

Organisations and teams need help to figure out what value is. Enter product management.

Product management puts the value in the agile manifesto

A narrow interpretation of Scrum can lead to a narrow interpretation of product management, in which a Product Owner is told what value is by a ‘senior stakeholder’, and then hoses this into their team. The Art of Business Value poses the question “is it possible that the product owner role feels like a good idea because it helps fit Agile practices into a command-and-control hierarchy?”.

But we should instead see product management in a different light.

“Rather than being the authority of business value, making business value tradeoffs down to the feature level, the product owner can also be seen as the visionary responsible for a product or system, the person who communicates a vision behind a product and steers its development and evolution, the person who establishes a high level business value context in which the team generates solutions.”

You could argue that as product managers it’s rare for us to manage a genuine product, but what is consistent about our role is that we manage value for our organisation and team (hey, maybe we should be called value managers).

As product managers, it’s our job to help our organisation figure out the business value context in which we operate, and to use this to build a vision which helps us to generate solutions. This applies to me as a product leader. Value is extremely context specific, so I’m not going to attempt to create some all-encompassing defition of value - instead I’m going to focus on the context in which I work, which is government. I’m going to attempt to create version 1 of a high-level business value context for government, with help from Mark Schwartz and his book, [The Art of Business Value].

Business value in government

What is business value?

The Art of Business Value suggests that “business value is a hypothesis held by the organisation’s leadership as to what will best accomplish the organisation’s ultimate goals or desired outcomes,” and I tend to agree. At its simplest, an organisation’s leadership assume that ‘if we do X and measure Y then we should see an increase in our value, Z’.

In a private company, you can argue that this hypothesis can be relatively simple because the value context is relatively simple: the goal of a private company is pretty simple, it’s to generate profit and return value to shareholders. Private value can be relatively simple.

Public value

The goal of government is not so simple. We run public services, for the public (which includes ourselves). We’re not trying to generate a profit. We don’t have shareholders. How do we figure out what public value is?

Mission value

We can begin the definition of business value in government by looking at non-profits:

“The ultimate financial objective of a nonprofit cannot be maximising sharedolder value, since it has no shareholders. According to John Zietlow, Jo Ann Hankin, and Alan Seidner in their book on nonprofit financial management, the correct financial concern for a nonprofit should be hitting targets for liquidity: having just enough resources to carry out the mission, but not too much. But even for Zietlow, who’s speciality is financial management, it would be misleading to think of business value solely in financial terms: ‘the public service nature of a nonprofit poses a major challenge in terms of identifying and articulating its mission and and developing criteria for measuring its success.’ The criteria for its success - that is, its definition of business value - is about accomplishing the mission for which it was chartered.” p.27, [The Art of Business Value]

Government is similar to this. Each government department and agency has a mission, and should be given sufficient money to achieve that mission. Our challenge is to define out mission and the criteria for measuring our success, and to achieve that mission whilst hitting targets for liquidity. This can be described as mission value.

So maybe public value can be defined solely by mission value?

Political value

No. Government is massive. Public value is not defined solely by the local mission of one team or agency. Her are some quotes from The Art of Business Value that I share without comment:

“A government agency has other value concerns beyond those directly related to its mission area […] it values fairness in procurement practices: all contractors and suppliers should have equal chances to compete for government business. It values transparency, public accontability, and the political goals of those in power. Clearly shareholder value is not what is meant by business value in the context of a government agency; even mission value might be rather an oversimplification. On the other hand, there are similarities between the public sector and the private sector. As Mark Moore points out, the goal of a public sector organisation can be thought of as delivering public value, just as that of a corporation is to deliver private value. Both types of organisation must make value-based trade-offs in the use of resources for which there is an opportunity cost, typically cash - in one case the cash of shareholders, in the other case the cash from tax-payers. The government is unique in that one of its resources is its authority to compel behaviour, but doing so also has an opportunity cost. The magnitude of the punishment for non-compliance, for example, is a cost to society. Moore examines several ways of thinking about public value […] agencies are generally given conflicting or inchoerent guidance by their political overseers.”

“When you ‘provoke and observe’ in the government environment, you discover what its true values are. The government is based on a system of ‘checks and balances’ - in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye - the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on ‘optics’ - how something appears to the observant public.”

“Public service in an environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk). […] When an agile team self organises to meet business needs and deliver business value, it cannot just consider customer and user needs for its products. It must consider all of the needs of the organisation and all of the things the business values, and then self-organise to meet all of those needs. The needs disclosed by bureaucratic rules are among those needs.”

Business value in government can be thought of as ‘public value’

Based on the above, my initial assumption is that business value in government can be thought of as ‘public value’.

Unlike private value, public value is not simple and consists of:

mission value
political value.

These two types of value may sometimes conflict with one another, and political value (in particular) maybe unclear, requiring a ‘provoke and observe’ strategy to identify.

To return to an earlier assumption: business value is context specific. So the next challenge is to explore public value in a specific context, that of the team and department in which I work, testing this notion of ‘public value’ in reality.

Leadership dimensions

2018-01-29T00:00:00+00:00

What does ‘leadership’ mean?

In my last post I shared that I need to pivot my professional development from product management to product leadership, which means that I need to figure out what ‘leadership’ actually means. The importance of ‘context’ became clear to me in my last post, so I’m looking to define what leadership means for me (rather than what leadership means in an abstract sense).

What does ‘leadership’ mean for me?

For me, leadership has several dimensions. This model has helped me to identify these dimensions and begin to think about them, and how I develop within them. The model was developed by my colleague Georg Fasching, who’s been working with me in a leadership coaching context for around a year (and agile coaching for a year before then). Georg has developed this leadership model during this time, based in part on the context in which I’m working (leadership team in a large enterprise with a matrix management structure, in the process of ‘digital transformation’), so based on my working relationship with Georg, the quality of his model, and our shared context, it works well for me.

If I take Georg’s model and personalise it for my needs right now, I understand leadership to have the following dimensions:

my self - I find it important to remember that I am not defined by my job, and 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 really important to me but my partner, my family, my friends, my interests and my hobbies (my real life) are more important to me. Both are important to me but my real life is more important than my work life.
people - My work life is shaped by people. I’m part of an organisation that builds user-centred (i.e. people-centred), public services. I’m head of the product management profession, so work with peers who share a passion for prioritising the most valuable problems that people face, and then working with other people to solve those problems. I guess I can summarise this as ‘empathy’: I need to focus on what empathy looks like in a leadership role, and how it helps understand and motivate people.
organisational improvement - I work in the ‘digital and technology’ function of a government department, which covers five organisations, consisting of seven business units. We’re just one function amongst many. We’re undergoing (and playing a lead role in) ‘digital transformation’. We’re helping to bring in-house software development to government, supporting the use of user-centred design across government (not just in software), and supporting prioritisation based on outcomes over outputs (typically known as ‘working with agility’). This is all within a function that has grown from 300-400 people, to around 1,000 people, in the last year. Oh, and we’re new to the idea of professions. What does leadership mean for me, within these contexts? And how do I get better at it?
value managment - I’m accountable for the value of a profession, as the head of that profession. We need to contribute to our teams being valuable, our organisations being valuable, our wider function being valuable, our department being valuable, . . . and government as a whole providing value for the taxes we pay. That’s a lot of contexts, and a lot of different definitions of ‘value’. There’s another layer here too. The profession of product management is focussed on value management. Product management is a strategic role, focussed on optimising the value of products and services. We, product managers, have a specific role in taking a lead in improving value management in the contexts in which we work. I, as head of product, have a specific role in taking a lead in improving our organisational strategy for improving the value of our work. I’d argue that, of all the dimensions, ‘value management’ (often called ‘business strategy’) is the dimension in which product management needs to step-up and play a lead role in helping their organisation to improve. For me, this is what ‘product leadership’ means: take all of the value management/product management that takes place within a delivery team, and apply it within a leadership team. It seems as though value management or business strategy is in its infancy, so there is a real opportunity for product management to step-in and improve it. I think that step one for me as a ‘product leader’ is to start identifying the value contexts in which we (product managers) work, within our organisation, so that we can (i) optimise our value within these contexts and (ii) identify value contexts that contradict each other (which feeds in to the ‘organisational improvement’ dimension).
time - Finally there’s time. Everyone has the same amount of time each day, 1440 minutes (as Georg says). I want to work regular hours, so that I can have a life outside of work. That means that I need to prioritise my work time, seeking to balance the time I invest in each of these dimensions (reviewing and correcting that time as needed, as the balance will need to change). So right now, I’m prioritising the ‘value management’ dimension to focus on. Value management motivates me as product manager, and seems like it’s where we have the most uniqe value to add as a profession. It’s also the dimension that I’ve made the least time to explore over the last year or so.

Next time: value contexts

To return to the beginning of this post, my leadership development will be most useful when I understand the contexts in which I work and think about what leadership means within those contexts. It’s clear that I’m most interested to explore the ‘value management’ dimension of leadership. I will prioritise the next post in this blog to think about what value looks like in the many contexts of government: what does it mean for product managers, and what does it mean for product leaders?

Afterword

Coaching is in the background of this post. I’ve coached and been coached for around ten years and have typically found it useful when I’ve ‘clicked’ with the coach or coachee, and the style of coaching is matched to the right context. In this post we’re seeing a situation where ‘executive coaching’ has helped, but there are many types of coaching. Kate Leto and Barry O’Reilly recently published this post which helps to explain the difference between a coach, a mentor and a consultant, and which summarises some of the value of coaching.

Coffee places: Prufrock at Present, Shoreditch

2018-01-21T00:00:00+00:00

Flat White might have opened in 2005, bringing the eponymous drink to these shores, but it wasn’t until 2010-ish that ‘artisan’/’third wave’ coffee shops started to go mainstrem - and a small concession in the front of a men’s clothing store seemed to play a significant part in this. ‘Prufrock’ was a coffee machine and a counter located in the front of a clothes shop called Present, in an area of London called Shoredtich. Prufrock influenced the rise of artisan coffee shops, punching well above its weight in terms of its physical size (there was a bench outside the store that could accommodate 2-3 people, and a single counter with a coffee machine in the front of the clothes shop). Why was this?

The coffee was really good. International-level good. Gwilym Davies was one of the founders of Prufrock, and he’d been running a successful coffee cart in an area of London called Whitecross Street for a while before winning the world barista championship in 2009. He set up Prufrock with (I think) Mattias Björklund in 2010, and I saw Jeremy Challender working in their a lot. These people really knew how to make a great cup of coffee.

There was a growing interest in great coffee from consumers (like me) and baristas at around this time but there remained a lack of people and places where you could learn more about it. Gwilym, Mattias and Jeremy seemed to be particularly generous with their time and support, and Prufrock became a bit of a mecca for coffee people who wanted to try the drinks and ask for tips. Speaking to people at the time, I think that lots of folks got help and support from Gwilym, Mattias and Jeremy, the tiny Prufrock concession creating a big impact.

I worked round the corner from Prufrock, in a place called Hoxton Square, and used to visit often - it’s one of the reasons I’m in to coffee now. I published a (now defunct) blog on coffee at the time, recording my exploration of this drink, and remember Jeremy Challender kindly agreeing to let me pick his brains about coffee. I was a complete n00b at the time, without a clue what I was doing, but he didn’t mind and chatted to me whilst making drinks. Someone from Keep Cup came in, and he generously told them I was a ‘coffee writer’ and they should speak to me, which set me up for my next interview. This seems to be a similar experience for a lot of people - Gwilym, Mattias and Jeremy being generous with their time, and generous with their support.

And then Prufrock moved. It’s now to be found in much larger premises (as befits its popularity) on Leather Lane. The teaching and support is now an explicit part of their business model, with a coffee school being run from their basement. What I find interesting is that you’d never really know about their roots in the concession of a clothes store in Shoreditch, as the internet has a pretty short memory. Lots of the posts written about it at the time are no longer accessible because the blogs that published them are defunct. I did manage to find this article on ‘The Cafe Hunter’, and this article in the New York Times. The real legacy, however, is in the coffee shops in Shoreditch itself. The digital and media crew working in Shoreditch had (and have) a huge appetite for coffee, and Prufrock helped pave the way for independent coffee shops in that area. Between 2010-ish and 2012/3-ish, it felt as though Shoredtich had stolen Soho’s crown for the largest number of independent coffee shops. Whereas Soho’s Italian-style independent coffee shops had been shrinking for years (I think the last one has finally closed), Shoreditch became the UK’s home for Aussie and Kiwi-style coffee shops. That’s not the case any more, they’ve spread across the UK since then, but for two or three years Shoreditch was the home of artisan coffee in the UK, thanks in part to a modest coffee concession in a clothing store.

Coffee places: Flat White, Soho

2018-01-20T00:00:00+00:00

A few years ago I finally made it to Flat White in Soho. Flat White is credited with being one of the UK’s first Australian/Kiwi style coffee shops that have now become popular, even ubiquitous in some cities. Opening in 2005, Flat White marked the coming to these shores of artisan, independent coffee shops that we now know as ‘third wave’ coffee shops. This meant that it was worth a visit for a coffee-fiend such as I during a mooch around Soho one afternoon.

More than this, I was interested in the Anitpodean connection between this unassuming coffee shop and the rise of independent coffee shops in the UK. Legend has it that the Lord of The Rings trilogy hooverd up lots of visual effects artists for several years, living in and around New Zealand and learning to love the artisanal, independent coffee shops they visitied during production. Following the completion of The Return of the King in 2003 the visual effects artists moved on to other projects, with many moving to the visual effects studios in London that were clustered around Shaftesbury Avenue. Studios like Double Negative were working on the Harry Potter and Batman film series around the time that Flat White opended just round the corner in Soho. These visual effects artists who’d developed a taste for atisanal coffee whilst working on Lord of the Rings in New Zealand were a match made in heaven for one the UK’s first antipodean, artisanal coffee shops.

I have no idea if this legend is 100% accurate or 100% false. The truth probably lies somewhere in the middle. What interested me most was that coffee shops can often have a real sense of ‘place’ at a particular point in time. Flat White marks the beginning of ‘third wave’ coffee becoming popular in the UK, and its success was tied to all sorts of things going on in Soho, and London more broadly, at the time. I’ve decided to explore some of the coffee shops that I’ve enjoyed drinking at over the years and the places they’ve served, in a series of posts called ‘Coffee Places’. First up will be Prufrock in Shoreditch.

Personal pivot. WTF is leadership?

2018-01-12T00:00:00+00:00

It’s a wonderful time

Simon Wardley published a thread of Tweets yesterday, with my take on it being that ‘business strategy is in its infancy, with organisations often relying on meme copying and gut feel; there’s an entire field yet to be discovered, to be understood - its a wonderful time.’

The last year or so has seen me starting to figure out what leadership (specifically product leadership) means to me, and my assumption is that business strategy is an important part of this. So Simon’s thread of tweets helped to collect my thoughts and, aided by a couple of strong coffees, I’m pulling together some early assumptions that I intend to explore over the next few years.

Pivot: product management –> product leadership

I’ve been working as a Head of Product for since 2016 and it’s taken me a while to get my head around the role.

I spent my career trying to do what’s most valuable, rather than what I was told to do, seeking out spaces where I can focus on outcomes over outputs. The role of Product Manager has given me the most opportunity to do this, so I’ve spent around a decade trying to hone my craft as a Product Manager in order to work with teams to maximise the value of projects, products, and services (you can see evidence of some of this in my blog). Over time, my role as a product manager started to bleed out into broader organisation and system improvement, which brings us to today. I need to improve my understanding of what the value of a Head of Product is - for myself, for my profession, and for my organisation.

I’m choosing to pivot, tweaking my professional development (and this blog) so that it no longer focuses just on product management but also focuses on product leadership and helps me to figure out what product leadership means. I think that, in the process, business strategy will become a key theme. In a recent post, I argued that the label of ‘product manager’ is rubbish at describing what we do and that we actually manage value: we maximise the value of projects, products and services by prioritising the most valuable problems to solve. Extending that logic, any space in which prioritisation takes place could benefit from product management. Based on this, I have an assumption that product management might help to improve business strategy.

WTF is leadership?

I assume that leadership is an activity carried out by everyone in an organisation. I’m starting to consider the following catgories (but expect to refine this and uncover more):

‘senior Leadership’ as a class of work within an organisation, often owned by a Senior Leadership Team or Senior Management Team
Leadership as an individual role within this team, with delegated responsibility for a particualr aspect of Leadership (this is where I think that product management might play a significant role within the space of business strategy)
(perhpas most interestingly) the distributed and shared actvity of leadership by everyone in an organisation based on delegated authority.

As I said, I have an assumption that product management as a profession can play a role in leading business strategy within an organisation. And in the above paragraph, it already seems that leadership means different things in different contexts. Simon Wardley suggests that a lack of context is a weakness of existing thinking on business strategy. Therefore, I’m setting myself the goal of acknowledging context when thinking about product leadership and business strategy so my next post will be a space to think about the contexts in which I want to think about leadership and business strategy.

Business strategy and product leadership

My leap of faith for the pivot from product management to product leadership is that we as a profession can be valuable in contributing to the development of business strategy. My thinking is extremely sketchy at this point in time, so excuse the rambling nature of this post. The next post should help to set some context and increase definition.

My favourite books, films and videogames in 2017

2018-01-01T00:00:00+00:00

These were some of my favourite books, films and videogames in 2017. They weren’t necessarily released in 2017, and 2017 wasn’t necessarily the first time I read/watched/played them, but they were all enjoyed in 2017 none the less.

Books

I tended to favour ghost stories, horror and science fiction.

‘All Systems Red: The Murderbot Diaries’ by Martha Wells

‘Beauty, Glory, Thrift’ by Alison Tam

‘The Gods of HP Lovecraft’ by Adam Nevill, Martha Wells, Laird Barron, Bentley Little, Jonathan Maberry, Brett J. Talley, Christopher Golden, Joe R. Lansdale, Seanan McGuire, Rachel Caine

‘The House of Shatterd Wings’ by Aliette de Bodard

‘The Phillip K Dick Mega Pack’ by Philip K Dick

‘The Power’ by Naomi Alderman

‘Wylding Hall’ by Elizabeth Hand

Films

I watched loads of ghost stories, horror and science fiction films but you’ll see some others too.

Berberian Sound Studio

From Bedrooms to Billions

Sennentuntschi: Curse of the Alps

Under the Shadow

Whitney: Can I Be Me

Videogames

Initially my preference was for open-ended loot shooters but I switched to adventure games with shorter run-times by the end of the year.

Destiny

Everybody’s Gone to the Rapture

Don't make espresso at home, probably

2017-12-24T00:00:00+00:00

Baristas don’t make espresso at home.

“Oh, I just use a French Press”, is a typical response to the question ‘what do you make at home?’. Making good espresso at home is a real hobby: it requires practice and some not inexpensive kit. The baristas I’ve spoken to seem surprised that anyone would bother with this.

I’ve been making espresso at home using a ‘manual’ machine (i.e. not capsules) for at least five years and I think I’m OK at it (I can probaby make a better espresso than you’ll get in most chain coffee shops and restaurants). But if I was faced with the option of starting this hobby now, with all of the knowledge I’ve gained over the last five years, I’m not sure I could be bothered.

Here are all the reasons why you probably shouldn’t bother making yourself espresso using a manual espresso machine.

Someone else can make it for you

You can get really good double-espresso made by a professional barista for £1.80-£2.50 from independent coffee shops in London. Baristas will use a professional machine that cost a minimum of £5K (and possibly up to £20K) and have a grinder that cost a minimum of £200, hence why the baristas I’ve spoken to think it’s a fool’s errand to try and make good espresso at home on a tenth of the budget. Baristas practice and refine their skills by making dozens (maybe hundreds) of espresso shots every shift. You’re likely to make less than five in any day at home (and not make any for days or weeks at a time) so your learning will be pretty slow (unless you have the time and interest to practice and maybe even attend a few lessons).

You can cheat

‘Pod-coffee’ like Nespresso wasn’t quite such a big thing in 2010/11 when I got in to coffee but today they’re a popular option. There are a bunch of automated espresso machines that use pods and make the whole process easy. The results are consistent and more than good enough for most people (who just want something smooth and coffee-tasting). You’ll get something decent straight out of the box (probably better than your first few attempts from a manual espresso machine). You’ll never get results to match those of a good independent coffee shop, or a manual espresso machine that you’ve learned to use properly but equally you can just plug it in and start using it. Two popular brands are Nespresso and Tassimo and I’ve had decent coffee from both. Downsides are: ground coffee goes stale quickly, so you’re always brewing with stale coffee; pods are expensive; pods create a lot of rubbish. Upsides are: the machines are well priced; you get consistent results; you can just plug-in and start using.

There are easier ways to make coffee at home

The reason that many baristas brew coffee at home is that it’s much cheaper and easier than making espresso. The full kit for brewing coffee using a French Press can cost less than £30 and the technique involved is simple, likewise for filter coffee. You can see the difference between these brewing methods in these photos I shared on Twitter.

Making espresso is an expensive hobby when you start

You’ll struggle to spend less than £300-£400 when you start. I’m not talking about top of the range kit here, I’m talking minimum quality needed to produce decent espresso.

Manual espresso machines

The steam wand is consistently rubbish in ‘cheaper’ espresso machines (those below £150ish). This doesn’t matter if you’re only making espresso but is a problem if you want to steam milk too. ‘Cheaper’ espresso machines may also have fixed-size of ‘portafilter’ (the handle you use to hold the coffee in place when making your espresso) which will limit you making single espressos. The De’Longhi Icona is an example of a manual espresso machine that you can buy for under £100, and as long as yuo acknowledge its limits then you’re getting a decent deal.

I own a Gaggia Classic which cost £180 but has actually gone up in price over the last few years, you’re now looking at £200-£300 for this espresso machine. The Gaggia Classic is extremely well built but had a couple of limitations that I was willing to accept in order to get a good deal:

the ‘basket’ (the perforated tray that holds the ground coffee) which comes with it is rubbish. It only has a single hole in order to create a lot of pressure. This helps to create an impressive-looking cream with every shot of espresso, but also messes up the coffee making process (water takes longer to come through the coffee grinds, which might start to burn; all the water comes through one section of coffee grinds so the flavour will become weak). I ordered a normal replacemet for £5
the steam wand it comes with was rubbish, being plasticy and unable to maintain the pressure required. the next ‘entry-level’ manual espresso machine at the time was called a Rancillio Silvia (currently costs £400-£500), which was double the cost of the Gaggia Classic. I followed an online tutorial and bought a Rancilio Silivia steam wand for around £20 (which is well made) and used it to replace the steam wand on my Gaggia Classic. This voids the warranty and requires some fiddling, but made a massive difference to my milk steaming.

I would have spent £400-£500 on a Rancilio Silvia if I could have afforded it, but the Gaggia Classic has turned out to have been a great choice. If money’s no object then you can buy some beautiful manual coffee machines for the home kitchen like the Rocket Espresso machine for upwards of £1,000.

Coffee grinders

‘Your coffee grinder is as important as your espresso machine.’ I repeatedly received advice to this effect when first sniffing around the world of homemade espresso but dismissed it at the time, assuming it to be something that coffee snobs say to justify spending huge sums of money on cool-looking kit. Now I realise that a good coffee grinder is worth the investment if you want the ability to make espresso from a wide variety of beans.

On a basic level the two things you’e looking for from a grinder are a consistent size of grinds and a low temperature during the grinding process (so as not to damage the coffee’s flavour) and my burr grinder is fairly good on both counts, within limits. I’ve got the De’Longhi KG79 Professional Burr Grinder (currently around £40), pretty-much the cheapest coffee grinder that you can get away with if you want to make good espresso at home. My grinder can just about grind fine enough for espresso . . . from certain types of beans, and this is where its limits kick-in. Coffee beans come in all manner of varieties and I simply can’t make decent coffee with some of them because I have such a basic grinder. In simplest terms possible, coffee beans are either dark-roasted (think traditional Italian coffee), medium-roasted, or light-roasted (think Aussie/Kiwi style independent coffee shops). De’Longhi is an Italian manufacturer and the KG79 handles dark-roasted, Italian style beans really well; it can cope with medium-roasted beans; and is can’t cope with lightly roasted beans (which often require fine-tuning).

What does this mean for your choice of grinder?

if you like dark-roasted beans then you’re pretty well catered for at the low-cost end of the grinder spectrum, as this is the comfort zone of the Italian manufacturers
if you favour medium-roasted beans then you might be able to get away with an Italian grinder, or you might need to invest in something a little more sophisticated like the newly released, well reviewed and well-priced ‘Wilfa Grinder’ (isn’t technically an espresso grinder but digging in the reviews seemed to suggest otherwise) at around £100
if you want to make espresso from light-roasts then you need to shell-out a few hundred quid in order to have the ability to fine tune your grind size, maybe something like a Mahlkonig Vario Espresso Coffee Grinder at £300-£400, or you might be able to pick up something like a second hand Mazzer Mini on ebay for £200-£300.

I’ve remained pragmatic and chosen beans that will work with my grinder. Allpress is one of my favourite coffee roasters, and their house espresso blend is at the dark end of medium-roast which means that my grinder can just about handle it. Workshop Coffee is another of my favourite roasters but I found that their roasts, often ligher or more exprimental, just wouldn’t work with by <£40 grinder.

My grinder is decent but remains the weakest-link in my espresso gear.

. . . and the rest

You’ll need a whole lot more kit.

Digital scales. You’re dealing with tiny quantities of ground coffee when making espresso, so benefit from scales that go to a decimal point. I use American Weighing Scales AC-650 but these seem difficult to get hold of and have doubled in price (£20 when I bought, now £40). If you don’t already have digital scales accurate to 0.1g then there are options on Amazon for less than £10.

Tamper. When your coffee grinds are flat in the basket and there aren’t any cracks in the surface, it means that the water will run evenly through the coffee and produce a decent espresso. Your tamper is your tool to make this happen. I used a plastic, double-sided tamper (bought for £5) for a couple of years before finally upgrading to something a bit more sturdy for around £30. The benefit of a ‘proper’ tamper was that I could choose a base that fit snuggly in my basket (therefore tamping all of the coffee grinds), and the weight of the tamper made the job much easier and more effective.

Water. The majority of your espresso is water. The ‘harder’ the water, the higher the total dissolved solids it already contains and the less of your coffee can be dissolved in to it. London tap water is hard and will make your coffee taste bad. A water filter will improve the taste of your espresso and extend the life of your machine (by slowing the build-up of limescale).

You might also consider:

a Knock Box (£10-£20) to stop you from getting used coffee grinds all over the kitchen
a Tamping Mat (£5-£20) to stop you from denting your kitchen surface when tamping the coffee in the coffee basket.

Still here?

OK, all the sensible people have decided that life’s too short to spend over £500 and over 6 months of trial and error in order to make decent espresso at home. That leaves me and you: people who like the challenge of learning a new skill and becoming good at it over time. If you’re really committed to making espresso at home the truth is that it can be fun and provides an excuse to find out more about the wonderful thing that is coffee. I’ve been making espresso at home for around five years now and can now knock-out consistently decent results like this.

You can kick-start your understanding of espresso by taking a class. I’ve been on a few coffee courses including an espresso class at The Department of Coffee and Social Affairs. The upside is that these classes are a chance to play with really expensive kit and get tips from someone who’s made thousands of great shots of espresso. The downside is that these classes are not geared towards making espresso at home with domestic kit, so you might need to adapt what you learn for your own kit.

You’ll quickly exhaust the espresso help readily available online and end up at a great resource like Coffee Forums UK. These forums helped me to understand how to use my Gaggia Classic - it was great to read that the basket and steam wand really were rubbish (and it wasn’t just me not knowing how to use them) and that they could both be replaced. The upside to these kind of forums is that they’re aimed at helping people to use domestic (rather than professional) kit. The downside is that I’ve found some bad advice has become accepted to be true.

Mostly what I’ve learned is that you have to find what works for you and go with it. The coffee world can be a bit snobby and wilfully exclusive but ultimately espresso is just water with dissolved solids for flavour. You can change the ratio of water to dissolved solids, and the method of dissolving solids in to the water. Espresso is typically 1 part coffee grinds, to 2 parts beverage: so for a double espresso you might grind 14g of coffee beans and extract a 28g, double-shot of espresso (plus an extra few grams of mass for the creama, the silky head on top of the espresso). This is only a starting point, and you should find what works for you. The ‘perfect shot’ is the one you enjoy the most, ignore anybody who tells you has to be done a certain way.

Using the kit and beans mentioned above, my current favourite recipe for a double-shot of espresso is

16g of coffee grinds
Extract 30g of espresso
Expect up to an additional 3g of crema once extraction has stopped.

You’ll notice that I use mass as my primary gauge, others will use extraction time as their primary gauge. Neither is ‘right’, you just use what works for you.

There’s a whole world to explore in making espresso, and we haven’t even touched on steaming milk yet. If you’re looking to get a quick coffee then manual espresso is probably just a time-suck. If you’re looking for a hobby and the satisfaction of mastering a new skill then it can be a great thing to learn.

How to brew French Press coffee

2017-10-08T00:00:00+00:00

A French Press is an ‘immersion’ brewer, meaning that the coffee is fully immersed in water during the brewing process. This means that a lot of the ground coffee dissolves in your drink, creating a full-bodied, strong cup of coffee. This is how I make 250g of coffee using a French Press.

Kit

water filter
French Press
Hario Mini Mill Hand Coffee Grinder
Salter digital scales
funnel
kettle
stirrer
mug
timer

Ingredients

coffee beans
filtered water

Method

Boil the filtered water and leave to cool a little
Measure out 17g of coffee beans (note 1: The guidance is 6g coffee beans per 100g of coffee, making 15g coffee beans for a 250g mug, however this is only a guide and should be tweaked for personal preference. I seem to get my best results from 17g coffee beans; note 2: To measure the coffee beans, I place the grinder on the scales without the arm or the lid but with the funnel in it. I then zero the scales and pour out the beams. This prevents the beans from going all over the place)
Grind the coffee beans (note 3: This has the benefit of letting the boiled water cool by a few degrees; boiling water poured immediately onto ground coffee can burn it)
Once the boiled water has cooled, place the French Press on the scales; remove the plunger, pour the ground coffee inside and zero the scales; pur in 250g water and stir
After four minutes replace the plunger and gently push-down until all coffee grinds are trapped at the bottom of the French Press. Pour the coffee and enjoy
Leave the coffee until it’s cool enough to taste, then drink.

The product manager is dead. Long live the value manager.

2017-09-17T00:00:00+00:00

The label of ‘product manager’ doesn’t usefully describe what I actually do.

I was recently introduced a new colleague. They said ‘Ah, you’re a product guy!’, then asked me about software to print large collections of documents. Their assumption was that, as a product manager, I am something close to a walking catalogue of products - which is fair enough, with a title like ‘product manager’, right?

In reality, it’s been years since product managers were people ‘from the business’ (possibly a senior and trusted technical specialist or subject matter expert) who would be placed in to a development team to decide what features they should build. Today, product management is a distinct profession in its own right - that wasn’t as true even four or five years ago. Product management in 2017 is more likely to be about creating a strategy that maximises the value of a service, working with a team to set goals that descrbe what the increase in value looks like if they’re successful but leaving the team to figure out how to do it.

We don’t yet have a label that usefully describes what our profession really does.

I think that the ‘product manager’ is dead, and the ‘value manager’ is emerging to take their place.

Identity crisis in product management

Look at the product management posts and talks of 2017 and a pattern emerges. We’re having a crisis of identity. This is clearest in the ‘product owner or product manager?’ posts and talks. Melissa Perri summarises this discussion succinctly:

“Product Owner is a role you play on a Scrum team. Product Manager is the job {…} A good Product Manager is taught how to prioritize work against clear outcome oriented goals, how to discover and validate real customer and business value, and what processes are needed to reduce the uncertainty that the product will succeed in market. Without this background in Product Management, someone can effectively go through the motions of Product Owner role in Scrum, but they can never be successful in making sure they are building the right thing.”

Roman Pichler has recently written a similar post:

“The confusion stems—at least partly—from the fact that Scrum is a simple framework focused on helping teams develop software. It does not cover common product management practices, such as, product strategy development, product roadmapping, and financial forecasting; and the only product management tool it offers is the product backlog.”

Government product management (my current bit of the product world) has been exploring this too, with Ross Ferguson saying that government needs the skills of product managers rather than product owners, and Zoe Gould essentially agreeing but saying that we shouldn’t get too hung-up on labels. Ross and Zoe get on well and are making the same point: that, whatever we’re called, the important thing is to be clear what makes us valuable in a team. And what we as Heads of Product in government have agreed is that product ownership is just one of the capabilities needed to be a valuable product manager.

The main theme I took from this year’s Mind the Product conference was product managers (myself included) admitting that we hadn’t chosen product features in years. The role of the product manager has become one of strategy and value, helping teams to set goals that describe and increase in value then getting out of the way and empowering the team to figure out how to do that. Martin Eriksson’s post from earlier in the year acts as a summary of the message we heard time and again throughout the conference: we are not the CEO’s of our products, our role is to lead by setting clear goals that hold teams accountable but also empower them to own the solutions. Martin’s closing remarks for this year’s conference were that the label of ‘product manager’ hasn’t really fit the role we do for a while now. I’ve been thinking the same for a while too.

Can we learn anything useful from the origins of the product management profession?

It started with soap

A product is something that you buy and own, like soap. I have never managed a ‘product’, despite having been a product manager for over a decade. A service is something you use but do not own, like Netflix. This better describes the things I’ve worked on. So why are we product managers?

‘You’ll be a little lovelier each day with fabulous pink Camay’

It’s 1931. Neil McElroy is in charge of promoting the Camay soap brand for Proctor & Gamble. Neil is frustrated that Camay always plays second fiddle to P&G’s leading brand, Ivory.

“In a famous memo to management, he argued for the creation of the role of “brand manager”. This person would take overall responsibility for the commercial success of a product, managing it holistically like a business in its own right.” - The Practitioner’s Guide to Product Management by Jock Busuttil, p.10

P&G agreed, and Neil paved the way for the profession of product management - our profession grew out of managing genuine products, in such a way as to maximise their value.

Agile and software and scrum, oh my

It’s 2001. The manifesto for agile software development has been created by a group including Ken Schwaber and Mike Beedle in February, and then Ken Schwaber and Mike Beedle publish Agile Software Development with Scrum’in October (quick work, huh?). In 2002, Schwaber and others will found the Scrum Alliance. The agile manifesto and accompanying principles say that we should seek to maximise the value of software, by prioritising features based on how valuable and delivering them asap. The scrum framework interprets the agile manifesto as a framework for development teams to use, and names product managers as the members of the team who prioritise the features to be developed, based on how valuable they are. The scrum framework also chooses to rebrand product managers as ‘product owners’. Neil McElroy’s vision of someone managing a product and running it like a business in its own right has been taken and rebooted for software, by the scrum framework . . . promoting the role of product manager in the process under the banner of ‘product owner’.

In 2001, software is still predominantly sold in shops, in boxes, on discs. It is something that you buy, and own. It is a product, so a product manager/owner makes sense.

There is no cloud, it’s just someone elses computer

It’s 2011. ‘Software as a service’ is now a thing. SaaS describes a shift in the relationship between businesses and consumers where by consumers rent use of software, with consumer hardware acting as terminals that access software that remains stored on the businesses computer, via the internet. In the realm of ‘cloud computing’, we no longer own the software we use. Software ceases to be a product and becomes a service. This leads to a huge shift in production, with successful companies breaking traditional barriers between design, development, operations, sales and marketing in order to have the much quicker sales cycles needed to compete in this market. Annual sales cycles for software products don’t cut it for software as a service: massive projects and formal handovers between departments are a good way to go out of business. Co-located, cross-disciplinary teams are increasingly standard.

Which means that product managers need to adapt. The traditional scrum product owner, focussed on software features, does’t work when each product mission needs to include work on your service wrapper, sales, and marketing - all of whom are likely to be part of the product team. Communities like ‘Mind the Product’ emerge, publishing their now famous article what exactly is a product manager?, which attempts to figure out what product management means when we no longer manage products. The now ubiquitous overlapping circles place product management at the heart of user experience, technology, and business - showing what the scrum product owner role, focussing on new features, does not encompass the skills needed of a product manager.

A product is (usually) not a business

. . . which brings us back to today, and our current identity crisis in product management. As anyone who has taken or taught on the General Assembly product manager course will know, ‘a product is (usually) not a business’. A product or service is only valuable when it is in the hands of a user, and getting software in the hands of a user takes more that just new features. A ‘product manager’ is accountable for the strategy by which the value of a product or service (and, increasingly, it’s a service) is maximised. We’re generalist amongst a team of specialists, hired to be the person in a team who’s passionate about the problem and the value of solving that problem, rather than the solution itself. We succeed when we help the team to prioritise its activity to best increase the value of the service, through data-driven prioritisation of goals. We manage value, not the product or service itself. The product or service is built and operated by the teams we work with.

We manage value. We own the strategy by which we maximise the value of services.

Value manager

Lots of product managers do not manage products, they’re managing services. It’s no longer enough just to help teams decide on the new features of their service, we need to focus on the ‘so what?’

how will this actually increase the value of the service, for users and for our organisation?
how do we hold ourselves accountable for increasing the value of our service, and empower our teams to use their combined skills to achieve this increase in value?

I’d like to propose that we are value managers, not product managers.

In The Art of Business Value, Mark Schwartz argues that we’re increasingly working in complex adaptive systems, typified by rapid change and complex interactions, in which we can influence but not control outcomes. The function of product management is to provide context and incentives that nudge the system towards its desired outcomes. We cannot, and need not, have perfect information - our challenge is to create conditions that move the system as a whole towards the value-outomes we want.

This is a fancy way of saying what me and others have been seeing for a while, and what came through time and again at the Mind the Product Conference: our role is to prioritise and set clear, value-driven goals that maximise the value of services by holding teams to account and empowering them to be their best.

The template for a good ‘goal’ to be set by a leadership role like a product manager is outlined by Barry O’Reilly:

We believe [this capability]
Will result in [this outcome]
We will have confidence to proceed when we see [measurable signal].

This value-driven approach works at all levels of an organisation: from a user-story on a team backlog, to a mission on a services’ roadmap, to a whole-organisation’s corporate strategy.

In 2017, this is what is needed from product management: value-driven strategy that can work in complex, adaptive systems and nudege services and organisations towards their goals. Total control and perfect information are not possible today, if indeed they ever were, and we need to introduce confidence through an adapative, data-driven approach that’s always linked to the ultimate goal: increasing value for our users, and our organisation. This is why we’re increasingly seeing product management moving into the leadership space, with roles such as Lead Product Manager, Product Director and Chief Product Offier much more visible than they used to be. Value strategy applies to the organisation as a whole, not just the individual products and services it creates.

The product manager is dead. Long live the value manager.

Afterword

. . . so, obviously we can’t just stop using the label of ‘product manager’. I’m responsible for recruitment and know that if I started advertising for the role of ‘value manager’ then I would not get many applicants. So we need to keep using the label of ‘product manager’ for practical resons . . . for now at least :)

But what I believe we can do is be more explicit about the truth that what product managers are accountable for is maximising value through valule stratgy, rather than just ‘the product’ and its features. It’d be great to get your take on ‘value management’ as described in this post, it’s still an early idea so I’d like to test it and improve it as much as is useful. Say hello on Twitter or Github if you’d like to talk.

There’s a bunch of things I re-read when writing this post that I didn’t have space to reference but are worth sharing anyway:

Ken’s Nortons famous, 2005 essay on the role of product manager
You can trace the ‘product manager as CEO’ theme back to Mark Butje’s 2005 book Product Marketing for Technology Companies, but what I find interesting is that he actually says ‘the product manager is a weird person - someone who takes on an enormous amount responsibility without actually being in charge. Sort of like a CEO but without the hierarchic power’
Martin Eriksson has given a much better history and evolution of product management than the one given in this post.
> this time last year, the government heads of product created the first draft of the capabilities and levels of mastery we expect of associate product managers, product managers, senior product managers, lead product managers, and heads of product.

How to brew filter coffee

2017-09-04T00:00:00+00:00

The filtering process removes some of the coffee beans’ oils and solids. This leads to a relatively light brew, helping you to notice the coffee’s moredelicate flavours. This is how I make a 250g of filtered coffee to go in a mug.

Kit

water filter
Hario V60 Ceramic Coffee Dripper
filter papers
Hario Mini Mill Hand Coffee Grinder
Salter digital scales
funnel
kettle
mug

Ingredients

coffee beans
filtered water

Method

Boil enough water for your drink with some to spare
Place the filter cone on the mug and line it with a paper filter
Pour enough of the boiled water onto the paper to make it completely wet. This ensures that your coffee won’t have a ‘paper’ taste
Measure 17g of coffee beans into the grinder (note 1: The guidance is 6g coffee beans per 100g of coffee, making 15g coffee beans for a 250g mug, however this is only a guide and should be tweaked for personal preference. I seem to get my best results from 17g coffee beans. Note 2: To measure the coffee beans, I place the grinder on the scales without the arm or the lid but with the funnel in it. I then zero the scales and pour out the beams. This prevents the beans from going all over the place)
Grind the coffee beans (note 3: This has the benefit of letting the boiled water cool by a few degrees. Boiling water poured immediately onto ground coffee will burn some of it)
Place the mug, cone and filter on the scales then pour the ground coffee into the filter and zero the scales
Slowly pour 250g the off-boiled water over the coffee grinds (note 4: Pour slowly and ensure that you move the stream of water and cover all the grinds. Don’t just hold it in one place or you’ll not get the flavour from all the grinds)
Leave the coffee until it’s cool enough to taste, then drink.

10 experiments you can try to improve discovery

2017-08-19T00:00:00+00:00

Want to improve your discovery? Here are 10 things you and your organisation can try to make your discovery even more valuable, based on a recent retrospective of discovery.

Experiment 1: Can’t interview? Don’t start.

Data/research suggests that

teams can wait for weeks to carry out their first interviews with users when they have to develop a route to users. This means that the first few weeks of discovery may have limited return on investment and the final weeks are over-loaded with interviews and do not have enough time for the team to draw conclusions before discovery ends

So if we try

starting discovery when the first interview can take place within 3 days

And measure

time taken for first interview
time taken to complete discovery
% of discoveries requiring extensions
confidence in discovery insights

We should see this change

better insights from discovery (with ‘better’ defined as team and stakeholder confidence in these insights)

Experiment 2: Subject matter experts are invaluable

Data/research suggests that

subject matter experts being a core member of a discovery team increases the value of the discovery (and may reduce the time taken to complete discovery)

So if we try

increasing the involvement of subject matter experts with the core discovery team (where this is useful)

And measure

% of discovery team ceremonies attended by stakeholders
time take to carry out first user interview
amount of time spent with users during discovery
% of discoveries that require a deadline extension

We should see this change

greater confidence in outcomes of discovery (and potentially shorter discoveries).

Experiment 3: Don’t be too digital

Data/research suggests that

discoveries carried out by ‘Digital’ teams will tend to skew discoveries towards digital solutions (i.e. in-house software)

So if we try

Digital ‘plus’ teams (better mix of ‘the business’/policy/analytical services, etc and ‘digital’)

And measure

% of discoveries that lead to digital solutions

We should see this change

greater balance of digital/non-digital solutions

Experiment 4: Lean Startup over Scrum

Data/research suggests that

‘pure’ Scrum is not a great framework for discovery and alpha because it expects requirements and value to be defined up-front

So if we try

a hypothesis-driven approach as described in The Lean Startup

And measure

% of discoveries that do not continue to alpha
% of discoveries that pivot the problem, or user, or both
% of discoveries that recommend pausing until conditions are right for alpha
% of discoveries that suggest that ‘digital’ isn’t the best, or only solution space to explore in alpha

We should see this change

data-driven decisions in discovery; teams able to share the hypotheses how they’ve tested to draw conclusions as to the value of a problem being solved.

Data/research suggest that

dysfunction can appear during discovery due to a lack of shared understanding of the value of discovery, and the approach to discovery
members of discovery teams may not have the same understanding
discovery teams and their Service Manager may not have the same understanding as ‘the business’/stakeholders

So if we try

sharing discovery guidance

And measure

% of discovery team members, Service Managers and stakeholders that can consistently describe the value and approach to discovery
stakeholders/’the business’ satisfaction with discovery

We should see this change

teams encounter less dysfunction due to uncertainty around the point of discovery and the approach to discovery, and stakeholders’ expectations around discovery being met more consistently.

Experiment 6: Don’t reinvent the wheel

Data/research suggests that

some of the core concepts of discovery and alpha (new to government) share more with project management concepts (familiar to government) than we expect

So if we try

highlighting similarities between agile development and project management
learning from project management
sharing guidance on when project management is the best approach, and when working with agility is the best approach

And measure

% of ‘work’ that makes an informed choice in the best model (agile or project) based on the conditions in which it’s working

We should see this change

the right approach is taken for the right ‘work’ because there is greater shared understanding of how the approaches work and the value of their differences.

Experiment 7: Show me the money

Data/research suggests that

discovery teams would like greater accountability

So if we try

making discovery teams aware of their budget and the rate at which they are spending it

And measure

the average cost of a discovery

We should see this change

average cost decreases

Experiment 8: What’s a pre-discovery?

Data/research suggests that

pre-discovery has become a common stage of development but has yet to be clearly defined so is used inconsistently

So if we try

defining the value of a pre-discovery stage, and deciding if it should exist, and (if ‘yes’) applying it correctly

And measure

number of pre-Discoveries that take place in the future versus in the past
% discovery teams reporting that a pre-discovery helped their discovery

We should see this change

pre-discovery of more use to discovery teams Or
pre-discovery of more use to portfolio Or
pre-discovery no longer used Or
???

Experiment 9: Clearer briefs

Data/research suggest that

discovery teams can spend several days (sometimes over a week) clarifying the brief for a discovery

So if we try

a consistent approach to discovery briefs

And measure

average time spent by a team defining the brief

We should see this change

teams begin discovery sooner

Experiment 10: Run regular discovery retrospectives

Data/research suggests that

the questions used to carry out the retrospective that led to these hypotheses worked well

So if we try

team/organisational discovery retrospectives using similar questions

And measure

responses

We should see this change

improvement in discovery.

Notes

note 1: I wrote a post about product roadmaps in which I highlighted a format for hypotheses shared by Jock Busuttil and have used that format for this post
note 2: it’d be great to hear from anyone who tries any of these hypotheses or has suggestions of their own, say hello on Twitter or share suggestions on Github.

10 things we learned about discovery in government

2017-08-15T00:00:00+00:00

UK government has been a trailblazer in the use of discovery, one of the reasons it has become a world-leader in user-centred design. Discovery is the most critical and most challenging phase in developing a new public services, so a few of us from digital teams decided to see what’s been learned from the first few years of discoveries in government so that we can do even better over the next few years.

Background

Me, Rob Banathy, Helen Mott, Rob Stirling, Iain Gordon ran the retrospective. We spoke with 25 people from the service management, product, delivery, research and design professions, from several government departments. The things we learned have been shared in a Google Doc for the last few weeks but some government departments can’t access Google Docs and a few people outside of government said they’d like to see what was learned too, so here they are on an easily accessible blog.

You can find out more about how this retro began and the questions we asked in a previous post.

Retrospective prime directive

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.”

Summary of themes

Pre-discovery is a thing
Briefs for discovery vary
Teams rely on their professional experience when carrying out a discovery
Teams expressed a desire for more guidance on discovery
Service Manual guidance on discovery has limited use
Time taken to complete a discovery varies
Teams would like to learn from other discoveries
Discoveries have been valuable in stopping work where there is a weak business case, or the conditions to proceed to alpha are not present
Business case for a solution comes at the end of alpha
Discoveries sometimes blend into alpha.

Pre-discovery is a thing

Work often happens before discovery officially begins, and this is often alled ‘pre-discovery’. We currently lack a definition of pre-discovery (it can currenrly signify any work that happens before discovery officially begins).

Things we might want to explore:

Is pre-discovery used to test the case for a discovery happening? In which case, is it better described as something like ‘discovery proposal’?
Is pre-discovery used to build the brief for a discovery team? In which case, is it better described as something like ‘discovery initiation’?

Brief for discovery varies in format, clarity, and route to team

The format for a brief can vary from conversations, to emails, to clear briefing documents. This does not necessarily matter, in itself. However, Service Managers and teams report that they can spend time (days, sometimes more than a week) clarifying the brief for discovery.

Things we might want to explore:

Does this match our expectation of how a discovery should begin?
Do we expect clearer briefs before a discovery begins?

Teams rely on their professional experience when carrying out a discovery

Teams report that they rely on their professional experience when approaching a discovery, over explicit guidance (e.g. good practice, other examples of discovery, etc).

Teams expressed a desire for more guidance on discovery

Despite relying on their professional experience, teams expressed a desire for more guidance. This is a tricky one to draw conclusions from and deserves more digging but an early assumption is that a problem with relying on professional experience when approaching discovery is that everyone’s experience is different. It seems that this can lead to a situation where a team all believe that they understand the same thing by the term ‘discovery’ . . . but don’t understand the same thing, in reality - which can lead to dysfunction.

Service Manual guidance on discovery has limited use

The majority of people are aware that it exists but few reported more than cursory use of it.

Things we might want to explore:

Does it need to be better?
Do teams need to be connected with it more consistently?

Time taken to complete a discovery varies significantly

Most of the discoveries we heard of took between 4 weeks and 3 months to complete but also heard of a discovery taking 6+ months.

Things we might want to explore:

Does this matter?
Some delivery teams and Service Managers report frustration with the time taken to complete discovery
Some teams think that discovery could have been completed more quickly if they could access users quicker, and if they could work more closely with stakeholders and subject matter experts
Scope of discovery seems to vary and it may be that there are different ‘scales’ of discovery.

Teams would like to learn from other discoveries

Teams expressed a desire to see what has been learned in previous discoveries, in order to avoid duplicating work. However, they said that they hadn’t found an easy way to find out about previous discoveries within government and that it can sometimes be difficult within their own departments.

Things we might want to explore:

Is the expectation that discovery insights should be shared within departments and cross-government?
If so, does this happen already?
If not, how do we make it happen?

Discoveries have been valuable in stopping work where there is a weak business case, or the conditions to proceed to alpha are not present, saving money for the tax payer

We heard of two discoveries that did not proceed to alpha.

Things we might want to explore:

We’d expect to hear of more discoveries don’t proceed to alpha or are paused, are there more examples out there?
Is there an expectation that discovery should lead to alpha?
Are teams empowered to pivot to such an extent that discoveries are sufficiently refined that they will tend to proceed to alpha?

Business case for a solution comes at the end of alpha

Teams reported an expectation from stakeholders that the discovery would produce a business case for a solution, however teams expect this to come at the end of alpha.

Assuming that the point of:

discovery is to prioritise a problem to solve (having explored several problems)
alpha is to prioritise a solution to the problem (having explored several solutions)

then it was felt that point of alpha is to product a business case for a solution (not discovery).

Things we might want to explore:

Do ‘digital’ teams and ‘the business’ mean the same thing when they use the term ‘business case’
Are ‘digital’ teams doing a good enough job at explaining the point of discovery and alpha?

Discoveries sometimes blend into alpha

Teams reported that discoveries sometimes blend into alpha without as much checking/approval as they would expect, given the quality checking that goes on for the other stages of the Service Manual. Most typically, a discovery is summarised in a slide deck and presented to key stakeholders, who make a go/don’t go decision.

Next post: hypotheses for improving discovery.

Run a retrospective on your discovery

2017-08-14T00:00:00+00:00

Want to run a retrospective on your organisation’s approach to discovery? Discovery is the most critical stage in developing a product or service so it’s important to learn from past experiences and improve. Here’s an approach that a few of us took in UK government, it’d be great to know what other people have done.

How did we get here?

Back in March, I asked the following question in the cross-government Slack: “Would at least a couple of other people be interesting in creating a cross-government, discovery community of interest?”

My assumptions were that:

discovery is hard
it’s often the most difficult phase for teams
it’s often the phase where wide-ranging insights and challenge is the most valuable
people have done it before and a lot has been learned that can be shared more widely.

Fast forward a couple of months, and a bunch of us decided to run a retrospective of UK government’s use of discovery over the last few years, so that we can learn and improve. The things we learned have been shared in a Google Doc for the last few weeks but some government departments can’t access Google Docs and a few people outside of government said they’d like to see what was learned too, so here they are on an easily accessible blog.

I’ve taken the approach of splitting our retro into three posts in order to keep things short and snappy:

this first post explains the questions we asked in our retrospective
the second post will share the themes that emerged from our retrospective
the third post will share hypotheses for improving discoveries, based on the themes that emerged.

What did we ask in our retrospective of discoveries in government?

Rob Banathy, Helen Mott, Rob Stirling, Iain Gordon and me developed these questions, that worked pretty well following a couple of tweaks and additions. Hopefully these questions are useful if you want to carry out your own retrospective - if we all use similar questions then it will help to compare findings.

1.What was your discovery?

What was the problem space? (very short description!)
Were you a stakeholder or part of the development team?
Did you have to meet the Digital by Default service standard because of the number of transactions your service would process, or did you chose to be Digital by Default?
Was the problem space quite undefined or well defined?
How much budget did you have for the discovery? Was there any budget set for the delivery?
Was it for a high profile delivery? Was it urgent?

2.What did you do during your discovery?

How did you know where to start?
Where did your brief come from?
What were the outputs?
What were the outcomes?
How long did it take?
How did you feel about the Discovery once it was finished?

3.How did you know who know who should be in your Discovery team?

Who was in your discovery team?
Where team members full time?

4.Did you have any blockers to discovery?

5.What discovery guidance did you use? Any recommendations for particularly useful guidance?

6.Post-discovery (in Alpha or Beta, for example) did you find something you wished you’d uncovered during discovery?

7.Is there a write-up, case study or blog about your discovery? If not, would they be willing to work with?

Next post: themes that emerged from our retrospective of discovery in government.

The Agile Manifesto for Public Services

2017-06-03T00:00:00+00:00

The Manifesto for Agile Software is 16. It’s no longer a ‘new’ thing to try out and feels as established as what came before it . . . so established in fact, that we should return to source and ask the question:

Is the manifesto for agile software as valuable as it was in 2001?

The answer, for my money, is ‘yes’ . . . and not just for software but for public services too.

I had the conversation in real life recently with my colleague Georg Fasching, and we agreed that if you replace the word ‘software’ with ‘public services’ then the manifesto and principles are great for building public services that are judged on how valuable they are for users and the organisations we work for (not just on their adherence to cost and delivery milestones). Features of public services should be designed and prioritised by how valuable they are, and value should be delivered as quickly as possible in small increments.

Sixteen years on, here’s a return to the agile manifesto - tweaked slightly to apply to public services (whether or not they are software).

The Manifesto for Agile Public Services

We are uncovering better ways of developing public services by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working public services over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agile Manifesto for Public Services

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable public services.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working public services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and development teams must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working public software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, development team, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximising the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organising teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What do you think, is the Manifesto for Agile Software Development still valuable at the age of 16?

Background

Me and Georg both felt that ‘simplicity–the art of maximising the amount of work not done’ is the principle that public services would most benefit from focussing on, since many public services are unnecessarily complicated and could be much more valuable for users and government organisations if they were simplified. What do you think?

The Five Stages of Applying the Digital Service Standard to Technical Stuff

2017-04-26T00:00:00+00:00

1. Denial

You “I’m working on a platform/API/component/infrastructure product/etc . . . it’s a technical ‘thing’’ for internal use, the Digital Service Standard doesn’t apply.”

Inner You “Yes it does. You know it does. Look deep within yourself young padawan.”

2. Anger

You “It’s not public facing! It doesn’t even have users! It’s an internal, technical thing!”

Inner You “Civil servants are users too. User-centred design ftw. “

3. Bargaining

You “OK, I get that it’s got users . . . but loads of the standards don’t apply. How do I do something like ‘be consistent with the rest of GOV.UK including design patterns and style guide’ when building something like an API? That’s not applicable. Be reasonable!”

Inner You “Developers are users. They need technical documentation to use the API. Technical documentation = content. The page that the content sits on needs to be designed. The value of your API is only released if the technical documentation works. Your API needs a service wrapper. You’ve created a service. The digital service standard applies.”

4. Depression

You “But that means that I need a multidisciplinary team. I’ll never get a User Researcher for this work. Or a Content Designer.”

Inner You “You also need that team to exist for as long as your technical product exits. If it becomes a critical dependency for multiple other products then a service desk, incident response and iteration are crucial . . . “

You :(

Inner You “. . . but teams around government are making this case successfully! Platforms, components and technical products are increasingly going the the same phases of development as public-facing services. Here’s the Alpha assessment for PaaS from almost a year ago.”

5. Acceptance

You “So . . . I can get a multidisciplinary team to work on my technical thing, that is really a service for internal users? That’s exciting.”

Inner You “Yes. You’ll need to help your colleagues understand that you’re working on a service, the same as them, but once they do then you’ll get the help you need.”

You :)

Discovery

2016-12-27T00:00:00+00:00

Discovery for Product Managers in Government

Note

This post is a work in progress published on GitHub where you can leave comments and suggestions.

Discovery is hard.

There’s recently been chatter about the discovery phase within the government digital community here in the UK, acknowledging that it can be hard to do well and that we can improve. This is something that’s emerged here at the Ministry of Justice (where I’m lead product manager) and across government during the development of a cross-government product management community of practice). Will Myddleton just published a post covering a lot of the stuff that makes discovery hard.

I’ve been chatting with Helen Mott (Head of Delivery at the Ministry of Justice) about discovery and Helen’s been working on explaining it from a delivery perspective. I thought it’d be useful to do the same from a product management perspective.

I’m a product manager, wtf is discovery?

Discovery is the initial design phase for public services in which you check if there’s a problem, if it’s worth solving and if you’re the best people to solve it.

I’ll repeat that because it’s my main point. I think that I should ask three questions during discovery and then work with my team to answer them with enough certainty to kill or continue the product:

is there a problem?
is it worth solving?
has it been solved already?

You’re unlikely to answer these questions in order and are likely to jump around all three, with insights in one of them changing the others.

Is there a problem?

Make sure your users want your service before you build it.

You should be talking about problems when you start a discovery phase. You should not be talking about solutions.

Your job as a product manager is to avoid committing resources (money, people, time) to a solution until you believe there is sufficient certainty that the solution is valuable. This approach is based on decades of product insights and was pulled together in The Lean Startup. The Lean Startup brings a management approach to areas of extreme uncertainty (like developing a service) focussed on validated learning, rapid build-measure-learn feedback loops, and measurement and accountability. It’s about taking a scientific approach to decision making. So you start by defining the problem that you want to solve.

You need to find out if there are people who will truly see the value of your product. This means that it’s not enough to simply spot a problem (e.g. ‘the current paper form takes ages and goes missing loads’), you need to dig deeper. Jock Busuttil was previously lead for the MOJ’s product community and has written a product management book called The Practitioner’s Guide to Product Management that identifies a key set of questions to be answered about the problem you want to solve:

Is it pervasive? Who specifically has the problem and does it affect lots of people?
Is it urgent? Do those people need the problem to be solved right away or can they wait?
Is it complex? Are people able to solve the problem for themselves or do they need someone else to solve it for them?
Is it valuable for users? How painful is the problem for them and would they be willing to change their behaviour and use a new or different solution?
Is it valuable for your organisation? Will solving the problem save more money than it costs to build the solution?

You are likely to reframe your problem during this process and may even change your primary user. This is important and valuable as you the scope of your problem to be feasible to solve. You’ll often find that you start with a massive problem space and refine this to something with a narrower focus but greater feasibility of being solved. The Institute of Design at Stanford’s design thinking process has been knocking around for longer than The Lean Startup and refers to this as a define mode in which you “unpack and synthesize your empathy findings into compelling needs and insights, and scope a specific and meaningful challenge. It is a mode of ‘focus’ rather than ‘flaring’.” This is important: the two goals of the define mode are to develop a deep understanding of your users and the design space and, based on that understanding, to come up with an actionable problem statement

Suggested reading:

Is it worth solving?

Looking at Jock’s questions about the problem you want to solve, you’ll notice that a couple of them refer to a solution. This doesn’t mean that you’re expected to build or even choose a solution at this stage but it does mean that you should have done the minimal exploration of potential solutions needed to make a decision about whether or not to spend money on a solution in later stages (i.e. should you proceed to Alpha). You’re looking to find what Steve Blank calls problem/solution fit. In short, do you have a problem worth solving?

You should work with your team and use validation techniques in order to make scientific decisions. List your assumptions and prioritise them in order of risk then run experiments to test these assumptions, framing each assumption as a hypothesis and providing clear pass/fail criteria for the test. In this way you will you will refine your problem and potential solution.

In practice, you might want to work on a physical board or a Trello board and:

have a huge braindump of assumptions
label them as user assumptions, problem assumptions or solution assumptions
decide on your core assumptions
prioritise your riskiest assumptions
design an experiment to test the assumption
agree the pass/fail criteria for the experiment
run the experiment and use the outcome to inform your decision making process Repeat this until you have refined you have enough data to make a decision as to whether you should kill or continue with the product.

I was asked to give an example of an assumption. Until recently I was Product Manager for the MOJ’s Cloud Platform, the hosting, deployment and testing service for developers. We had assumed that devlopers needed bespoke settings and concierge services but our user research showed that there is limited variety in MOJ software and developers wanted a simple setup process. This meant that we were able to change our approach, focussing on standardisation, sensible defaults and self-service for developers (which allowed us to save over 70% of hosting costs, amongst other things).

You can explore solutions at this stage without committing to building one. The Lean Startup defines a minimum viable product as the minimum needed for a build-test-learn feedback loop. This doesn’t have to be code, it can be things like paper wireframes, digital wireframes or using an existing solution as a proxy. You shouldn’t commit to a solution at this stage but you should run experiments to test if your problem is feasible to solve.

Suggested reading

Has it been solved already?

Let’s assume that you’ve found a problem that is valuable and feasible to solve. You should carry out market research to find out if someone has solved it already. If you think that your problem is likely to be solved by a case management system and you find an existing commercial option that seems to fulfil your users’ needs at a low price then you might want your Alpha to focus on testing this (rather than building your own).

A lean canvas is an excellent way to bring all of your insights together and ultimately decide if you should go ahead an try developing a solution to the problem you’ve identified. In his blog post It’s Time to Fire the Business Plan for Good, Ash Maurya uses a helpful visual representation of how your lean canvas is likely to develop during discovery, as you learn more about the users, their problems, and the possible solutions.

A lean canvas is a modification of a business model canvas, something I’ve previously blogged about.

For me, the key section of the lean canvas is the ‘unfair advantage’ section. You should only continue with a product if you have an ‘unfair advantage’ when it comes to developing a solution. In government this means that we shouldn’t always assume that building in-house is best. If someone elsewhere in government or a commercial organisation already has a solution then we should consider using that instead. As a product manager, we should ensure that we don’t recreate the wheel.

The bottom line

It all comes down to the bottom line. Literally. Adapting the lean canvas for government, the goal of discovery is to uncover COSTS (cost of the problem; cost of the solution) and VALUE (what is it worth to solve the problem?). As a product manager, your job at the end of discovery is to have established whether or not the value outweighs the costs, and to give the degree of certainty you have in your decision.

Top discovery fails

Here’s my personal list of top discovery fails:

falling in love with your solution
no clear return on investment
no clear path to users
flaring instead of focussing
a weak unique value proposition
no unfair advantage story
problem isn’t specific enough
lack of metrics of success.

General Discovery articles

8 things I learned about data discoveries, Kieron Kirkland - GDS
Discovery from Day One, Dan Mutton - ThoughtWorks

ENDNOTES

Here are a few things that I’ve not yet managed to incorporate in this post:

You can stop something after Discovery; equally, a single discovery could lead to mulitple things; be good to have examples of both

Alpha and service assessment: what’s the handover to alpha? how to engage with continuous service review at discovery?

Can I use real life examples to bring this to life or would it make the post too long?

Team: who are the right people for discovery? The product manager poses the questions in this post but answering them is a team sport.

Portfolio management: this post pre-supposes that discovery teams receive problem statements. What do you do when your a discovery you’re handed already pre-supposes a solution?

Account management: do our ‘clients’ understand the discovery phase when they commission work of government digital teams?

I haven’t mentioned vision, and have limited strategic tools to the business model canvas/lean canvas. How does the roadmap fit at this stage? This post is a useful one to pick up on this point: http://www.slideshare.net/sachmonkey/the-art-of-product-management-58156816

https://www.thoughtworks.com/insights/blog/discovery-day-one
https://twitter.com/CarlaDownes/status/821813084092301313

Product Managers: glue code for insights, not mini CEOs.

2016-11-14T00:00:00+00:00

Influence vs. authority

The blog posts from a few years back saying ‘product managers are like CEOs’ are responsible for some bad product management. Product managers are not like CEOs, especially in mature organisations. We’re not like an old school boss. We’re generalists acting as glue code for the insights of specialists. We manage the product through influence, not authority, something that relies on trust and respect. Nothing destroys trust and respect quicker than over-confidence and a superiority complex, so here’s my contribution to the blog posts debunking the myth of ‘product managers as CEOs’.

Humble beginnings

I’ve got sympathy. One reason for the CEO myth is that lots of product managers have to work with very small teams and end up doing lots themselves. When I worked for startups and charities I was typically expected to carry out market-sizing, user research, service design and delivery management as part of my role, with funding to hire a developer and visual designer from an agency. I had to do a lot with very little, which meant doing it myself.

Mature organisations

I’ve since moved to a mature software organisation within the Ministry of Justice, creating public services in the form of in-house software. It took me a while to adjust to having a team of specialists available to do things that I’d previously had to do myself. A discovery team might consist of a user researcher to understand users’ needs; a technical specialist to help understand the possible solutions; a business analyst to help understand the cost of the problem vs. the value of the solution; and a delivery manager to make sure that the team is performing well. I’ve had to make peace with the fact that product management in a mature software organisation is a non-functional role, and that I’m much more like glue code for insights than I am a CEO.

The value of generalists

There’s a real value in a non-functional generalist amongst a team of functional specialists, and that’s the role fulfilled by product managers. We know the minimum required of all the specialist roles within the team to bring their insights together whilst allowing them to focus on their area of specialism. Our value is in cutting across professional boundaries, acting as glue code that adapts insights from separate specialisms and allows them to interoperate.

Get over yourself

So if you’re a product manager in a mature organisation that you might have to get over yourself. You’re not the boss. You’re not more important than everyone else. You’re glue code that adapts insights from separate specialisms and allows them to interoperate within the context of the product. You’re a generalist amongst specialists . . . definitely not a mini CEO :)

Digital by Default Prehistory

2016-04-17T00:00:00+00:00

Before the Government Digital Service there was the ‘Business Customer Insight Forum’, tasked with ensuring that public service design was led by ‘customer insight’. This is a ‘customer insight’ briefing I wrote for the senior management team at the Training and Development Agency for Schools in 2008.

The Cabinet Office seeks to establish ‘customer insight’ as a strategic asset in public service design.

CSR performance framework for government (October 2006) makes clear the need for effective customer engagement and personalisation in services. In his Review of Service Transformation, Sir David Varney recommended that cross-government work on customer insight be focused on the citizen and business perspective. A ‘Business Customer Insight Forum’ (BCIF) has been established to provide expert guidance, via the main Customer Insight Forum, to the Delivery Council on the use of business customer insight and engagement in relation to the Service Transformation Agreement, which says that:

Citizens’ time is not free, yet often the way public services are delivered assumes it to be so. The aim of this Service Transformation Agreement (STA) is to change public services so they more often meet the needs of people and businesses, rather than the needs of government, and by doing so reduce the frustration and stress of accessing them. The result will be services that are better for the customer, better for front line staff and better for the taxpayer.
Services are defined as: “the full range of interactions that take place between service provider and user via a designed business process”.

The BCIF exists to support cross-government business insight projects, including giving advice, joint resourcing, and work on cross departmental customer journeys. It also provides a forum for the sharing of both best practice and research findings and helps to keep account of key business insight activity in departments so that work is not duplicated in other areas and opportunities for joint working can be identified. The BCIF seeks to optimise service delivery channels.

‘Customer Journey Mapping’ is seen as key to gaining customer insights, and three types of journey mapping are outlined:

Customer experience mapping is a qualitative approach, focussed on emotional insights about a customer, in order to tell his or her story with passion and narrative. It’s a powerful way of engaging both staff and customers.
Mapping the system, or process mapping, maps the steps in process and identifies where to act to make the experience as easy, pleasant and efficient as possible.
Measuring the experience is a form of mapping that allows you to determine how well an experience is delivered. It can quantify the effect of changes and contribute to a business case.

Customer journey mapping helps to:

See things from the customer’s point of view
Deliver information, messages and services at the most appropriate time
Deliver a seamless, streamlined experience that cuts across silos by recognising where and when it makes sense to join things up for the customer
‘Get it right’ when it really matters e.g. when emotions are highest or need greatest
Look at the current situation and the ‘ideal’ side-by-side, giving a chance to genuinely redraw the customer journey.

Customer journey mapping helps to build efficiencies in the following ways:

Bring about change across government in a way that cuts across silos
Target limited resource for maximum impact
Plan the most efficient and effective experience by reducing duplication and shortening the length of processes
Identify ‘baton-change’ points where service or communication breakdown is most likely
Identify problems and issues without attributing blame
Identify cheapest ‘cost to serve’
Set performance indicators and standards so that progress can be tracked and measured over time.

Trying GitHub Pages and Jekyll

2016-04-09T00:00:00+00:00

tl;dr

I’ve blogged using WordPress since 2009 but been frustrated that backing-up posts wasn’t easy. Greater familiarity with GitHub is useful for my current product. GitHub hosts a free, static site for each user through GitHub Pages. GitHub Pages can be married with Jekyll to create a blog hosted on GitHub.

Intro

I’m writing this blog post using Markdown and publishing it as a static website thanks to GitHub Pages. The blog is powered by Jekyll. This post to explains how and why I’m doing this.

How

Jonathan McGlone has published an excellent tutorial. Follow it and you’ll create your own blog too. The tutorial assumes very little knowledge and covers Git (version control system), GitHub (hosting service for development using Git), GitHub Pages (free web pages from GitHub) and Jekyll (a ‘static’ site generator, based on templates). You’ll then start writing blog posts using Markdown.

5 Whys

Why am I cheating on WordPress?

1. GitHub

I’d like to become a more sophisticated user of GitHub and I assume that regular, practical use is the best way to learn.

2. Documentation

I’m a product owner and have written about the importance of separating my product backlog from my development team’s sprint backlog. However, I could usefully have more knowledge of their activity and feedback they receive from our users in the form of issues. We believe in the agile manifesto, including ‘working software over comprehensive documentation’, but what we’re finding is a need for more documentation so that we can remember and evidence user feedback and action we’ve taken as a result. Our delivery manager smartly suggested making better use of GitHub before creating a new artefact so any opportunity for me to increase my understanding of GitHub in a practical sense without becoming a drain on the team (i.e. asking them to spend time mentoring me) is valuable. Additionally, most developers seem to hate using Google Drive so I’m sure they’d be much happier if they could collaborate on documents with me via GitHub instead.

My personal website has been active for years and is clearly something I regularly work on, so re-creating it using GitHub Pages and Jekyll should give me opportunities to learn more about GitHub in a practical sense.

3. Backup

WordPress is awesome. Back in 2009 (when I became more interested in web development because of the products I was working on), WordPress was a fantastic way to get online quickly. I wrote a now defunct food blog called ‘The Boy Can Cook’ that had a regular audience in the hundreds and led to some cool things (reviews, events, freebies).

Working with charities, social enterprises and startups, WordPress has been (and continues to be) a great way to make your mark. Services I’ve led like Young Dads TV, Mind of My Own, and Disclose Me (to name a few amongst many) have all benefitted from the WordPress universe.

WordPress started with personal blogs. My personal website is where I have most regular contact with WordPress. My use of the blog has changed over time and now I don’t care how many readers I have, it’s a public place to figure things out, get insights from a handful of people and return to in weeks/months/time to see what my thinking was like at a point in time. I think of my blog as a public place for private thoughts. My posts have value to me and so I want to back them up. This is not easy in WordPress. It’s not impossible but it’s not as easy as other elements of the WordPress universe, so I’ve been looking for an alternative for some time now.

4. HTML

HTML is fascinating. HTML has emerged as a globally organised language and fundamentally changed the way we live our lives within twenty-five years. I recently heard a conversation between developers saying that websites written in basic HTML many years ago often remain functional and accessible. I’ve been playing with HTML on and off over the years, GitHub Pages gives me a chance to continue to do so (along with CSS) when editing the layout of the default home page and blog page of my site.

5. Time

I guess, ultimately, time’s moved on. WordPress was perfect for my needs when I first published a cookery blog blog back in 2009, and it was valuable for me to learn about it in order to inform services I’ve worked on over the last few years. I’m certain it’ll continue to remain valuable for the forseeable future. Now though, my technical understanding of HTML and CSS has increased and the world has moved on. GitHub, pages and Jekyll are more useful to me right now, so I’m going to get stuck in. Wish me luck!

Over

Do you use GitHub to get feedback from your users? It’d be great to hear how you loop it back into your Product Backlog. You can nudge me on Twitter and GitHub.

Technical Product Management for the Non-Technical

2016-02-28T00:00:00+00:00

How does a product manager without a technical background manage a technical product? After six months figuring this out I think the answer is ‘the same way they’d manage any other product, only more so’. Let me explain.

How does a product manager without a technical background manage a technical product?

Product Management: First Principles.

I’m the Product Owner for the Ministry of Justice’s Cloud Platform, providing digital by default public services with modern infrastructure as a service and web operations. I’m not a Technical Product Owner (i.e. I don’t have a background as a Web Operations Engineer) and was concerned that this would limit my ability to manage the product. Being so far out of my comfort zone has forced me to revisit my product management first principles. For me product management is about:

starting with user needs
challenging assumptions
empowering your team.

My concern has been that my lack of technical understanding is a blocker to all three of these principles. My boss challenged this assumption and suggested that my lack of technical knowledge may in fact be a strength, so I’ve taken these general product management principles and interrogated them in more detail using the definition provided by a specific framework.

Product Manager + Scrum = Product Owner

A product manager working within a scrum framework is called a Product Owner, and Product Ownership is relatively well defined. Here’s a diagram I’ve adapted from a blog post by Roman Pichler, showing what being a Product Owner entails (and situations in which you may not be given the chance to truly be a Product Owner).

Vision

You can see in the diagram above that a Product Owner sets the vision for their product. This requires them to define:

their users
the needs of their users
the product itself
the value of that product to the organisation.

A good vision showcases a product team’s understanding of their users’ needs and helps defend against forces attempting to distract you from fulfilling these needs.

A vision is not simply a place to record the highest paid person’s opinion (HiPPO) . . . a Product Owner should be empowered by their organisation to challenge HiPPOs (based on the Product Owner’s insights into users’ needs). There’s a good chance that in setting the vision for their product a Product Owner will need to challenge their own assumptions and those of their colleagues. A good vision showcases a product team’s understanding of their users’ needs and defends against forces attempting to distract you from fulfilling these needs.

Strategy

The product roadmap is a Product Owner’s tool for creating the strategy by which the product will move incrementally closer towards the vision, describing these increments in as much detail as certainty allows.

Senior Product Owner

You may be asked to look after multiple products as you become more experienced, given a title something like ‘Senior Product Owner’. If this happens then you’ll be much less ‘hands-on’, possibly looking after just the vision and strategy whilst delegating the tactics to more junior ‘Feature Owners’ or ‘Component Owners’.

Tactics

The product backlog is a Product Owner’s tool for collaboration with their development team, turning the vision and roadmap into incremental product development goals explained through user stories that the team can understand and break into tasks on their sprint backlog.

You might find yourself working on the product backlog with little influence over the roadmap or vision. This is OK (and fairly normal) on a mature product (where you may be managing a single feature amongst a much larger piece of software) but if you are Product Owner for a new product in which you and your team are setting the core features and you are not empowered to genuinely set the vision and strategy . . . then you may have a problem.

Ignorance is bliss

So, back to the MOJ Cloud Platform. Can I, a non-technical product manager, add value to a team building a web operations and infrastructure platform?

The answer is ‘yes’ . . . in fact being non-technical is a strength. Collaboration between me and the development team becomes essential if , for example, we’re to create a meaningful product backlog (‘backlog refinement’ is the name given to this activity within the scrum framework).

A non-technical product manager working on a technical product forces a team to genuinely work with agility and to do product management properly.

In the past I’ve been guilty of holding on tightly to backlog refinement to the extent that I probably missed out on valuable insights from my development team. Having been pushed outside of my comfort zone by working on such a technical product, I need to focus on users and rely on the development team to develop solutions to their problems. I really have to collaborate with my team in order to create a meaningful product backlog (as well as genuinely empowering them to take complete ownership of their sprint backlog). A non-technical product manager working on a technical product forces a team to genuinely work with agility and to do product management properly.

My job is to build empathy with our users, build and defend our vision, and present the development team with well-defined user problems to solve . . . their job is to solve these problems using their wealth of technical skills and experience. My technical ignorance has been a blessing in disguise. The last thing that a team of excellent technical specialists needed was another technical specialist and instead I’ve (hopefully) brought the thing that’s most valuable about product management: the voice of the user.

Waterfall, Scrum or Kanban?

2016-01-19T00:00:00+00:00

How do you decide to use waterfall, scrum or kanban to manage your product team?

Wanting to refresh my Product Owner skills I’ve just come to the end of the first day of a Certified Product Owner session in which Roman Pichler retrofitted the Stacey diagram to explain where waterfall, scrum and kanban are of most value.

Roman’s interpretation of the diagram:

A waterfall management methodology, like PRINCE2, is suited to simple products (i.e. high certainty and high levels of agreement) because it is a sequential approach based on setting an initial plan that is unlikely to change.
Kanban is suited to complicated products (in which a degree of certainty is balanced against an expectation of change) because it assumes that workflow is understood but that conditions will change. Mature software is an example of product that might be suitable for management by kanban.
Scrum is suited to complex products with little certainty because it focuses on short-term goals that validate assumptions and reduce risk. Software in development is an example of a product that might be suitable for scrum.

This model rings true from my personal experience and helpfully overcomes the snarky assumption that waterfall should never be used whilst also demonstrating its limitations.

Working in the UK government where the digital agenda is maturing one can assume that the strategy will shift from delivery to maintenance. I’m interested to see if the pervasive use of scrum shifts towards kanban.

Product in Public Services

2015-11-17T00:00:00+00:00

In August 2015 I joined the Ministry of Justice as a Product Manager as part of their work to transform public services. My prior product experience was with teams who were some combination of startup, social enterprise or charity so I’ve been trying to get my head around what product means in public services.

Minimum Viable Product Management.

The purpose of product management seems to remain the same whatever sector I’ve worked in.

I’ve had ~~drinking~~ product catchups with Morag McLaren, Analisa Plehn and Jock Busuttil for a couple of years that have helped me to improve my understanding of product management, and working as a Product Management tutor at General Assembly with Danny Ivatt & Chris Bradley in 2015 gave me a chance to get better at explaining myself:

Product Management is a strategic business role that helps teams to create the simplest, most valuable product they can: the minimum viable product.

Understanding the problems of users and stakeholders is key to this role, based on the principle that when we genuinely understand someone’s problem we can build the minimum viable product needed to solve it (and conversely, when we don’t understand our users we have to guess their needs and consequently build solutions to imaginary problems).

I’m taking the term ‘minimum viable product’ from The Lean Startup (in which it means “that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time”), and using it in a different way. In my interpretation, minimum viable product is a good way to describe the benefit of product management: by understanding users a product manager helps their team to deliver the most value with the least effort.

Product Managers should critically challenge assumptions about (i) Users, (ii) Problems & (iii) Solutions in order to generate insights that enable the team to prioritise their time. This is known as a ‘user-centred’ approach to product development.

A Product Manager will help a team to understand the needs of users and make simple, valuable stuff.

Product Management Principles

As a Product Manager you:

Start with users needs
Can prioritise user needs over the highest paid person’s opinion (users over HiPPOs)
Are passionate about problems (not dogmatic about solutions)
Set the vision for your product
Lead by influence (not authority)
Work with agility

so that your team produces the Minimum Viable Product.*

*MVP is for life not just Version 1. Every product iteration should continue to be a minimum viable product. Your insights will increase (hopefully) and as they do so will your definition of viability. A ‘mature product’ should remain a minimum viable product.

Reading, recommendations and networks:

Digital by Default

Working on digital services on the UK right now is a great opportunity to do stuff that matters. In 2013, government gave itself 400 days to transform 25 major services, making them digital by default and simpler, clearer and faster to use as part of the Transformation Programme. This work continues and has become a well-defined, cross-government initiative powered by a great set of design principles, service manual and service standards - all of which put the user first.

However, despite all of these amazing resources, the role of a product manager can sometimes be unclear. Since joining Ministry of Justice Digital and wanted to get my head around product management of public services so I’ve been discussing ideas with colleagues at MOJ like Kylie Mulholland, and across government.

What’s a Product?

In general terms, a product is a ‘thing’ or a service that is valuable to its users. Sounds simple(ish)? Product in government can be murky. There are application programming interfaces (APIs) and microservices . . . which are components driven by business logic rather than products with clear value for users . . . but which can be clustered to create a platform that does have a value proposition and thus become a product.

## Product without Revenue

Working on products in government can feel a little abstract because we lack the certainty of revenue. Revenue sits behind product management in a commercial setting, the ultimate anchor of a business model: is the cost of your business activity less than the revenue it will generate (i.e. is it profitable)?

Public services lack this clarity but there are still ways to test your success. The Cabinet Office requires digital services to measure four types of data in order to measure their success:

cost per transaction
user satisfaction
completion rate
digital take-up (the proportion of transaction completed online).

Currently these four measures of success seem to complement each other but it’s feasible that in the not too-distant future, when the ‘low hanging fruit’ has been digitally transformed, user satisfaction and completion rate may be at odds with cost per transaction. There may also be a case for a measure of technical debt: architectural decisions made during development may give a low cost per transaction in the short term but shorten the lifespan of the software; conversely, adopting an architecture like that of microservices could mean that there is no short term reduction in the cost per transaction but lengthens the lifespan of the software and enables a more dramatic cost reduction in the future.

I’ve come into contact with Social Return on Investment when working on product and services for charities and social enterprises but (honestly) I found it to be a complex way of measuring success (New Philanthropy Capital summarised SROI a few years ago).

Assisted Digital

The unique thing about working on product in public services is that you’re building something for everyone in the UK - you’re not chasing product/market fit in the same way that you would elsewhere. Public services are ‘digital by default’ but about one in five adults is offline or has low digital skills.

I’ve worked on digital products aimed at offline adults before but they were only aimed at offline adults - it’s a different type of challenge to develop something for online and offline users. I’m looking forward to the this challenge and am looking forward to my first assisted digital support project - helping the most in need and the most isolated is something you rarely get the chance to do.

DevOps for Product Managers

2015-10-17T00:00:00+00:00

Help for Product Managers trying to understand ‘DevOps’.

I recently joined the Ministry of Justice Digital team as Product Manager for the Cloud Platform. MoJ Digital’s Platforms team provides all of the technical infrastructure needed behind the scenes, powering the applications developed to transform public services.

Dave Rogers (Head of Technology) suggested that I read ‘The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win‘. The book explains the importance of integrating software development and IT, otherwise known as ‘DevOps‘, and is a helpful tool for any product manager trying to learn more about digital infrastructure and the role of WebOps.

‘The Phoenix Project’ is also an exploration of what an organisation run by Kanban looks like. The novel introduces ‘The Three Ways’, a description of the values and philosophies that guide DevOps processes and practices.

“The First Way is about the left-to-right flow of work from Development to IT Operations to the customer. In order to maximise flow, we need small batch sizes and intervals of work, never passing defects to downstream work centres, and to constantly optimise for the global goals (as opposed to local goals such as Dev feature completion rates, Test find/fix ratios, or Ops availability measures).

The necessary practices include continuous build, integration, and deployment, creating environments on demand, limiting work in process, and building safe systems and organisations that are safe to change.”

“The Second Way is about the constant flow of fast feedback from right-to-left at al stages of the value stream, amplifying it to ensure that we can prevent problems from happening again or enable faster detection and recovery. By doing this, we create quality at source, creating or embedding knowledge where we need it.

The necessary practices include ‘stopping the production line’ when our builds and tests fail in deployment pipeline; constantly elevating the improvement of daily work; creating fast automated test suites to ensure that code is always in a potentially deployable state; creating shared goals and shared pain between Development and IT Operations; and creating pervasive production telemetry so that everyone can see whether code and environments are operating as designed and that customer goals re being met.”

“The Third Way is about creating a culture that fosters two things: continual experimentation (which requires taking risks and learning from success and failure), and understanding that repetition and practice is the prerequisite to mastery.

Experimentation and risk taking are what enable us to relentlessly improve our system of work, which often requires us to do things very differently than how we’ve done it for decades. And when things go wrong, our constant repetition and daily practice is what allows us to have the skills and habits that enable us to retreat back to a place of safety and resume normal operations.

The necessary practices include creating a culture of innovation and risk taking (as opposed to fear or mindless order taking) and high trust (as opposed to low trust, command-and-control), allocating at least twenty percent of Development and IT Operations cycles towards non-functional requirements, and constant reinforcement that improvements are encouraged and celebrated.”

Empathy and Digital Transformation

2015-07-23T00:00:00+00:00

In 2010, after five years of funding, managing and evaluating digital transformation within education, I reflected on what I’d learned and one adage stood out: technology is simple but people are complex. Fast-forward another five years (this time working on digital services in charities and social enterprises) and I’ve refined it further: empathy is at the heart of successful digital transformation. This was emphasised at yesterday’s Steering Group for New Philanthropy Capital’s Digital Transformation Programme (which I’m privileged to be a part of) where two messages particularly resonated with me:

‘Digital’ transformation can be a problematic because it runs the risk of focussing on digital for its own sake
The needs of real people should be the starting point for any transformation programme.

In short: technology is not intrinsically good or bad, it’s the alignment of technology with people’s needs that gives it value . . . and key to understanding people’s needs is empathy.

Don’t believe me? Andrew Lund of Google Enterprise shared his insights at Catch22’s recent Chairman’s Event, saying that effective digital transformation depends on three factors: technology transformation; cultural transformation; business transformation.

Google sees that technology is just one part of a larger picture within digital transformation. Too often organisations assume that transformation can be achieved by simply dropping technology in to their existing business and culture, when in reality this is what leads to expensive failures. I worked on a team that invested £20 million into teacher training over five years, supporting over 50,000 trainees via over 200 teacher training organisations and managed the evaluation of this investment. The key things most likely to lead to successful introduction of digital technology were:

Did it meet the needs of staff?
Did it meet the needs of trainee teachers?
Did staff and trainees have the time and support to learn how to use it?
Was it supported by senior management?

The digital technology itself was way down the list of factors. People and their needs were much more important. The teacher training organisations that achieved the most positive digital transformation were those that built the strongest empathy with trainees and staff.

Julie Dodd has created research more recently and more relevant to the charity sector called ‘The New Reality’, finding that successful transformation depends on four factors:

Mindset
People
Process
Tools

Once again we see that tools (including digital technology) play the smallest part in transformation, with people, processes and mind-set playing the major part. Technology has value when it aligns with the needs of people, and people’s needs are understood by building empathy with them.

Empathy is at the heart of successful digital transformation, which gives the charity sector a competitive edge over other sectors. None of us do our jobs because we want to get rich, we do it because we’re interested in people. Digital transformation is underpinned by conversations with staff and service users, building empathy and understanding their needs in order to create skills training for staff and service users, re-design business processes, redevelop organisational culture . . . and choosing some cool new tech.

UKGovcamp 15

2015-01-30T00:00:00+00:00

I attended UKGovcamp 15 last Saturday, had a bunch of thoughts on the day and wanted to sketch them out in this blog. The full UKGovcamp 2015 schedule is here and the full notes from the sessions are here.

UKGovcamp is a free annual unconference for people interested in how the public sector does digital stuff – my favourite description (seen on Twitter) was ‘Glastonbury for government digital geeks’.

I’ve been going to unconferences for years (and traditional conferences for years and years), this was my favourite to date. @harryharrold nailed it when he said there were deep, specific sessions – something that (un)conferences can often lack (I typically come away saying that lunchtime was the most valuable ‘session’ because it was the first opportunity to genuinely talk with people). There was enough structure to make the event run smoothly (and clearly enough learning from previous years to inform the structure). Sessions I attended were well organised and (importantly) were noted and shared by the end of the day (important to support reflection like this and to extend the learning beyond those in the room on the day).

My #ukgc15 ran something like this:

Blockchain and public services, led by @MartinHowitt, was a chance to get behind the buzzword and find out what it actually is. I found this film explaining Bitcoin and Martin wrote this blog post to share this thoughts. It’s fair to say that few people understand the technical detail of blockchain and that its value seems mainly metaphorical: something symbolic of decenrtalised power/fewer gatekeepers rather than a technical solution that will be widely used in public services in the UK in the short term.

Parliamentary Digital Service, led by Tracy Green was a chance to discuss how to reconnect a cynical population with legislative power and offer an alternatice to sometimes weak political press coverage. This session provoked strong emotions amongst govcampers, with particular disdain for outmoded voting processes. I was a policy analyst in a previous life and enjoyed parliamentary questions and select committees because they gave an immediacy and transparency to the parliamentary system – I’d love the new Parliamentary Digital Service to do the same thing.

@hindsightery and @lewisnyman brought us back to thinking about real people amongst all the chat of digital services. All roads lead to GDS and we talked around service design and starting with needs (with some interesting chat about user insights and guerrilla testing).

we got security screw-ups from @glynwintle, showing that even ‘techies’ can overlook the importance of security and that the main weakness of many digital systems are people. Added a capital letter and numbers to your password requirements? That means that everyone capitalises the first letter and adds a ‘1’ to it. World’s worst frequently used password? ‘123456’. Second most popular password? ‘password’. Ninth most popular password? ‘iloveyou’. Awww.

UKGovcamp was interesting on a personal level (hence this blog), will influence me professionally in my role as product manager for Propeller and has been fed into the wider system of public services - I’ve shared a UKGovcamp update with colleagues at Catch22.

Hacker, hustler or hipster?

2014-05-20T00:00:00+00:00

Ben Southworth spoke at Wayra yesterday and shared his opinion that there are three types of business personality.

1. Hacker

A digital, ‘business to business’ service built by developers, for developers. Uses great technology to make life easier for developers, who become advocates within their own companies (generating sales).

Stripe typifies this type of ‘hacker’ business, providing a smart payment system for developers to use.

2. Hustler

A digital service targeting middle-managers (often business to business), ‘Hustlers’ sell on benefits like ease of use, great customer service, and value for money. The technology does not need to be sophisticated (and might be relatively basic).

Mailchimp typifies this type of ‘hustler’ business, making electronic mailing lists quick and easy for people with limited time and technical ability.

3. Hipster

A socially driven, brand focussed business that relies on being ‘bang on trend’ and has social baked in. This type of business is beautiful and personal, often free, and might have a huge number of users but can be difficult to monetise (which leads to the question: is it actually a business?) . . . and remaining ‘bang on trend’ takes a lot of time and insights.

Instagram is a typical ‘Hipster’ that creates a loyal and passionate community of users (but struggles to find a business model).

What kind of business is yours?

Understanding the personality of my new business (a product management consultancy) has helped me to understand my customers and refine my value proposition. My business is a hustler, selling to middle managers: I need to sell simple benefits (like increased user engagement) rather than complex features (like technical explanations of product management).

Great businesses grow from conversations

2013-11-20T00:00:00+00:00

Two facts about me. I’m a user-centred product manager. I’m a professional coach. Until recently I viewed these as two, unrelated skills from separate points in my life but now I’ve recognised that they inform and support one another.

Coaching

I’m trained in ‘non-directive’ coaching. What does non-directive mean? It means that I believe that people have huge potential and have the ability to solve their own problems. A coach doesn’t tell someone what to do, they help them to figure something out for themselves. Just that act of talking through your ideas, out loud, can be incredibly powerful. This is know as ‘socialising’ your ideas.

A coach is more than an audience though. Part of my role is to take you to the limit of the your thinking, the point where you’ve got stuck, and then ask a critical question that stretches you, helping you to think in more creative ways. At the most fundamental level, this is done through conversation: a good coach will facilitate a conversation underpinned by something called the ‘GROW’ model. GROW stands for:

Goal
Current Reality
Options
Will (or Way Forward)

A coachee doesn’t work through these four stages in a linear fashion and so skill as a coach often entails listening and then confirming your understanding, often in the form of notes that help the coachee to see patterns that they haven’t noticed before, often leading to dramatic self-realisation.

Product Manager

User research is at the heart of my work as a product manager. I like to work on products that have a real meaning for me, supporting my local community. I’m also driven by creating services that people really want. This means that I have to really know the people I’m serving: good services aren’t designed by a room full of creatives plucking ideas from mid-air, they’re designed by understanding people’s goals and frustrations and being willing to change to fit real lives.

‘Discovery’ is an increasingly common stage of product development in which an organisation gets to know its users, defining problems before starting to develop solutions. Understanding the goals and frustrations of your users allows you to design something that they really value: it also allows you to deliver maximum value with minimum effort, something that allows for maximum return on investment.

You can think of ‘discovery’ as empathy. Empathy is the basis of long-term, productive relationships, and every organisation wants a long-term productive relationship with its customers.

Design by Coaching

For me, empathy is the point of intersection between coaching and user research. The first two sections of the GROW model, understanding someone’s goals and their current reality/frustrations, provide a way of understanding what empathy with a customer means. You develop empathy with your customers through open-ended conversations. You don’t barrel in with an idea and ask what they think about it because if you ask people hypothetical questions they’ll tell you what they think you want to hear. However, if you ask people to tell you about their life, and you’re genuinely interested in what they say, they’ll be surprisingly open and honest and provide you with insights you’d never of dreamed of.

Understanding the importance of empathy is powerful because it helps us to understand that great services don’t start with ‘killer ideas’, dreamt-up by god-like entrepreneurs. Great services start with conversations. Simple as that.

Business Model Canvas

2013-09-20T00:00:00+00:00

A product is (usually) not a business. A business model canvas can help you to understand what your customers value, create what they need, and ensure that your business is profitable.

The canvas works by breaking your business model into small elements that help you to work out the detail of the way your business needs to run to make money.

A product is (usually) not a business.

Why use a business model canvas?

Using a business model canvas might help you to realise that the amount of money you spend to acquire customers is less than the profit you make from them. You might choose to change the ‘customer relationship’ from personal assistance (e.g. every customer meets is served by a member of your team) to self-service (e.g. customers buy products online instead).

What does a business model canvas look like?

The business model canvas shown above was designed by JAM visual to represent the key elements of a successful business: there are a lot, aren’t there? It can be daunting to see all of these elements laid out for the first time – we often focus on ‘the thing we’re making’ or ‘the thing we’re doing’ (i.e. the ‘value proposition’) and don’t think about (or don’t want to think about!) all of the other elements needed to make a business a success.

Understand your customers and give them what they need.

Breaking down the business into these elements, and showing their relationship to one another is incredibly useful. The two most fundamental elements are ‘Customers‘ and ‘Value Proposition‘:

– ‘Customers‘ are at the heart of the business model and they are where you should start. Create a product or service for customers that you understand inside-out is easy. Creating customers for a product that you understand inside-out is hard. – ‘Value Proposition‘ follows from a great understanding of your customers. Which your customers’ problems are you solving?

Next, think about ‘Customer Relationship’ and ‘Channels’.

– ‘Customer Relationship‘: what’s the nature of the relationship between you and your customers? Think about shops: traditionally, buying books, music, and DVDs involved a customer visiting a building and exchanging money with an employee (personal assistance); Amazon disrupted this style of buying and allows customers to order goods online (self-service). Shops are disappearing whilst Amazon continues to grow. – ‘Channels‘: how will you reach customers? If you choose to advertise, how will you work out the effectiveness of advertising? If word of mouth is your best source of business, how can you incentivise your advocates?

What’s it worth?

What is the monetary value of your product or service? Understanding ‘Revenue‘ is fundamentally important:

what are your customers willing to pay?
What are they paying for similar products or services?
How do they prefer to pay?

Don’t limit yourself to charging for the ‘real’ value of your product. Fragrance is smelly water and costs pennies to make but costs huge sums to market: their marketing positions them as culturally significant and so their market value is a reflection of their cultural value (rather than their ‘real’ value).

Business operation.

Now switch direction and think about how you actually ‘do’ what your business needs to do – what’s involved in running your business?

– ‘Key Activities‘: how do you actually create and sustain your product or service? How do you reach your customers? How do you support your customers? How do you ensure payment? – ‘Key Resources‘: what do you need to carry out you business activities? Think about your team (managers? sales? ‘doers’?), your accommodation (office? building? home?), your equipment (computers? phones?), etc – ‘Key Partners’: do you need someone to help you find customers? Are their suppliers who are crucial to your business?

What’s it cost?

And finally, what does it cost to run your business?

‘Cost Structure“: what are the costs inherent to your business (i.e. activities, resources, partners)?

Is your business worth more than it costs?

The final assessment of your business model (and the main use of the business model canvas) is to help you work out if your business generates more than it costs. If ‘Revenue‘ is less than ‘Costs‘ then you’re off to a good start, but if not then the business model canvas will help you to fine-tune your business model. You might need to change your ‘Customer Relationship‘, or you may need to switch suppliers and sacrifice on quality for affordability. You may need to make more dramatic changes like moving to a different type of customer, or changing the product or service itself. Or you may decide that there isn’t a business model that works for you at the moment! It’s fine to fail, you just want to make sure that you fail fast and fail cheap.

So, how do you write a business mode canvas?

Start with customers
Meet the needs of customers
If costs are greater than revenue then try changing elements of the business model canvas to see what impact they have on profitability.

Remember, a business model canvas is just one tool amongst many. The important principles it embodies are customer driven product development and assessment of revenue vs. costs (e.g. profitability).

This article is a brief introduction to creating and using a business model canvas and you can find out much more online. A good place to start is the ‘Business Model Generation‘ handbook.

Manifesto for Agile Software Development

2013-05-18T00:00:00+00:00

I’ve just been on a SCRUM refresher and it made me think that now’s a good time to revisit the manifesto for agile software development (aka the Agile Manifesto).

“Manifesto for Agile Software Development.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.

That is, while we value the items on the right, we value the items on the left more.”

agilemanifesto.org

Lean Startup for Product Managers

2012-06-05T00:00:00+00:00

tl;dr

The Lean Startup by Eric Ries can help to create breakthrough new products (‘disruptive innovation’) that can create new sustainable sources of growth (p.31). Product Management enacts many of the principles outlined in the Lean Startup and is a useful touch-point for product managers. The pivot is at the heart of the Lean Startup: pivots represent the option to bulid, test and learn or to fail quickly and cheaply.

Introduction.

This post is a largely paraphrased overview of the Lean Startup (with page references to help you locate the original text).

The Lean Startup Method (p.8-10):

Working in areas of extreme uncertainty (entrepreneurship is everywhere)
Bring management to extreme uncertainty (entrepreneurship is management)
Validated learning (learn about your products and your business)
Build-Measure-Learn (accelerated feedback loop)
Accountability (Innovation accounting: measure, manage, prioritise).

[Lean Startup comes from] lean manufacturing, design thinking, customer development, and agile development (p.4).

Entrepreneurship is Management.

The concept of entrepreneurship includes anyone who works within my definition of a startup: a human institution designed to create new products and services under conditions of extreme uncertainty (p.8). Entrepreneurs who operate inside an established organisation sometimes are called “intrapreneurs” (p.26).

Entrepreneurship is a kind of management (p.3) and requires a managerial discipline (p.17).

[Lean Startup is] characterised by an extremely fast cycle time, a focus on what customers want (without asking them), and a scientific approach to making decisions (p.8).

Validated Learning.

It’s easy to kid yourself about what you think customers want and it’s easy to learn things that are completely irrelevant. Validated learning is demonstrated by positive improvements in the startup’s core metrics, backed up by empirical data collected from real customers (p.49).

Value VS. Waste

Learning is the essential unit of progress for startups. The effort that is not absolutely necessary for learning what customers want can be eliminated (p.49). Which of our efforts are value creating and which are wasteful? A common excuse for failure is that it was worthwhile because it enabled learning – was it the best way to learn that, or would talking to users have been more efficient? (p.47) Value in a startup is not the creation of ‘stuff’, but rather validated learning about how to build a sustainable business (p.182).

Get out of the building and speak to real people – behind all metrics & reports are real people. Run experiments to observe real customer behaviour (p.58) and avoid vanity metrics that give the illusion of success: focus on real progress. An experiment is more than just a theoretical inquiry, it is also a first product (p.63).

Example experiments (p.61):

The value hypothesis tests whether a product or service really delivers value to customers once they are using it
The growth hypothesis tests how new customers will discover a product or service.
Build-Measure-Learn feedback loop

build-measure-learn feedback loop.

Strategy is based on assumptions [. . .] because the assumptions haven’t been proved to be true [. . .] the goal of a startup’s early efforts should be to test them as quickly as possible (p.81).

Too many [. . .] business plans look more like they are planning to launch a rocket ship than drive a car. They prescribe the steps to take and the results to expect in excruciating detail, and as in planning to launch a rocket, they are set up in such a way that even tiny errors in assumptions can lead to catastrophic outcomes (p.21). Instead of making complex plans that are based on a lot of assumptions, you can make constant adjustments with [. . .] the Build-Measure-Learn feedback loop. We can learn when and if it’s time to make a sharp turn called a pivot or whether we should persevere along our current path (p.22).

We need to focus our energies on minimising the total time through this feedback loop. The two most important assumptions are the value hypothesis and the growth hypothesis [. . .] once clear of these leap-of-faith assumptions, the first step is to enter the Build phase as quickly as possible with a minimum viable product (M.V.P) (p.76). The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time (p.77).

The goal of such early contact with customers is not to gain definitive answers. Instead, it is to clarify at a basic, coarse level that we understand our potential customer and what problems they have. With that understanding we can craft a customer archetype, a brief document that seeks to humanise the proposed target customer (p.89).

A new breed of designers is developing brand-new techniques under the banner of Lean User Experience (Lean UX). They recognise that the customer archetype is a hypothesis, not a fact. The customer profile should be considered provisional until the strategy has shown via validated learning that we can serve this type of customer in a sustainable way (p.90).

Down the road – after many iterations – you may learn that some element of your product or strategy is flawed and decide it is time to make a change, which I call a pivot, to a different method for achieving your vision (p.113). ‘Innovation accounting’ leads to faster pivots (p.150) and entrepreneurs should pivot as soon as they can: failure to pivot is costly (p.169).

Accountability

When one is choosing among the many assumptions in a business plan, it makes sense to test the riskiest assumptions first (p.119). Metrics should be (p.142-146):

Actionable (clear relationship between cause and effect)
Accessible (plain English, easily understood, reflecting that metrics are people, e.g. what is a website ‘hit’?)
Auditable (data must be credible).

Innovation accounting – how it works in three milestones (p.117, 118, 120):

Use an MVP (baseline) to establish real data on where your company is at (value hypothesis and growth hypothesis)
Use iterative development to progress from this baseline to a more ideal state: have a hypothesis about what will improve
Metrics and a set of experiments designed to test that hypothesis
Pivot or persevere?

Pivot

A pivot is a special kind of change designed to test a new fundamental hypothesis about the product, business model, and engine of growth (p.172). When a company pivots, it starts the process all over again, re-establishing a new baseline and then tuning the engine from there. The sign of a successful pivot is that these engine-tuning activities are more productive after the pivot than before (p.118).

A startup’s runway is the number of pivots it can still make [. . .] a startup with a $1 million in the bank that is spending $100,000 per month has a projected runway of ten months [. . .] the true measure of runway is how many pivots a startup has left: the number of opportunities it has to make a fundamental change to its business strategy (p.160). A pivot is better understood as a new strategic hypothesis that will require a new minimum viable product to test (p.177). It is a special kind of structured change designed to test a new fundamental hypothesis about the product, business model, and engine of growth. It is the heart of the Lean Startup method. (p178)

Types of pivot (p.173-176):

Zoom-in pivot: something previously considered a single feature of a product becomes a whole product
Zoom-out Pivot: it becomes clear that a single feature isn’t enough for a whole product
Customer Segment Pivot: your product is targeted at the wrong type of customers
Customer Need Pivot: it becomes clear that the problem you’re trying to solve is not important for your customers
Platform Pivot: changing from an application to a platform (or vice versa)
Business Architecture Pivot: change from high margin, low volume to low margin, high volume (or vice versa)
Value Capture Pivot: Monetisation is an example of value capture
Engine of Growth Pivot: viral, sticky, or paid growth
Channel Pivot: change to the sales/distribution channel
Technology Pivot: deliver the same solution with different technology.

Growth

Sustainable growth is characterised by one simple rule: New customers come from the actions of past customers (p.207). There are four primary ways past customers drive sustainable growth (p.207-208):

Word of mouth (through satisfied customers)
As a side effect of product usage (Facebook gets you to invite friends)
Through funded advertising (for sustainable growth advertising should be paid for out of revenue, not one-time sources; cost of customer acquisition through advertising should be less than the revenue the customer creates)
Through repeat purchase or use (e.g. subscription, like mobile phone, or repurchase, like light bulbs).

Engines of growth (p.209-218):

The Sticky Engine of Growth: high retention rate – once you start using their product, you will continue to do so. Attrition (or churn) needs to be tracked closely – if the rate of new customer acquisition exceeds the churn rate, the product will grow.
The Viral Engine of Growth: Products that exhibit viral growth depend on person-to-person transmission as a necessary consequence of normal product use – Viruses are not optional. The viral engine is powered by a feedback loop that can be quantified, called a viral loopand its speed is determined by a single mathematical term called theviral coefficient: the viral coefficient measures how many new customers will use a product as a consequence of each new customer who signs up. Put another way, how many friends will each customer bring with them? For a product with a viral coefficient of 0.1, one in every ten customers will recruit one of his or her friends.
The Paid Engine of growth: work out how much you make on each customer and then subtract the amount it costs to acquire each customer. To increase the rate of growth you can increase the revenue from each customer or drive down the cost of acquiring a customer. The paid engine of growth is powered by a feedback loop called the lifetime value (LTV) – this is the amount of money a customer pays for the product over their lifetime minus variable costs. E.g. Advertisement costs $100 and causes fifty new customers to sign up. This ad has a cost per acquisition (CPA) of $2. If the margin between LTV and CPA is greater than $2, the product will grow.

Technically, more than one engine of growth can operate in a business at a time. (p.219). There are many value-destroying kinds of growth that should be avoided. An example would be a business that grows through continuous fund-raising from investors and lots of paid advertising but does not develop a value-creating product (p.85).

Scott Colfer's Blog

Movement Creates Clarity: How I Became Someone Who Finishes Writing a Book

1. Impulse and Permission

2. Discovery and Craft

3. Making and Momentum

4. Reflection and Revision

5. Expansion and False Starts

6. Completion and Release

7. Integration and Continuation

8. Beyond Product in Service

What I learned About Writing and Self-Publishing a Book

1. Constraint is freedom

2. Iteration is orientation

3. Conversation is editing

4. Tools are only useful when they disappear

5. Honesty scales better than hype

6. The writing of the book teaches the book

7. Completion is a form of integration

8. The niche is the gateway

Using AI Without Losing Yourself

Stage 1: False Starts

Stage 2: Building a Mirror

Stage 3: From Notes to Guides (and a Book)

The Constitution in Practice (Stark ↔ JARVIS)

Stage 4: Using AI Without Losing Yourself

5-Year Blueprint for Community of Practice

Stage 1: Explorer – Feeling the Terrain

Stage 2: Builder – Making It Last

Stage 3: Architect – Connecting Ecosystems

Epilogue – What I Learned

Field Notes vs Field Guides

Learning vs teaching

Why I’m choosing to share Field Notes

How I’m using this in practice

A note for anyone reading

Knowledge Metabolism

Transitions

Knowledge as content

Wayfinding: knowledge as creation

Metabolism

Just in case → just in time

Space to think

My Learning System 2025

I’m a heutagogue

Learning cycles & curatated knowledge networks

My learning system

Knowledge: field notes

Curation: field guides

Networks

Over to you

My book: 'Product in Service: A Manifesto for Pragmatic Product Management'

Good Training Leads to Lightbulb Moments that Create Change

A shared ‘lightbulb moment’ leads to change

A ‘lightbulb’ moment allows you to see clearly

Realisation

Good training

Make space for lightbulb moments with good training

What’s your take?

Professional Pivot: Director of Strategy and Transformation

Beyond product

Introducing

Coordination

Introducing New Wave Product

Start with why

How

What

Updates

Product Leaders for Good WhatsApp Community

Why

Who

How

What

My Social Media Triad for 2024: Substack Journal, GitHub Pages Blog, and LinkedIn Network

Substack Journal

Github Pages Blog

LinkedIn Network

The Science of Strategy

The Kernel of Good Strategy

No strategy survives first contact with reality

Let’s misquote Helmmuth Von Moltke